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ABSTRACT 


For  organizations  with  training  pipelines,  this  study  offers  insight  to  help  identify 
and  minimize  undesirable  effects  which  may  result  from  often  unavoidable  demand 
variations  within  a  resource  and  time  constrained  environment.  The  highly  complex 
Naval  aviation  training  process  is  used  as  a  case  study.  However,  any  organization  with  a 
training  pipeline  may  find  this  study  to  be  useful. 

Within  a  training  pipeline,  like  any  resource  constrained  production  line, 
variability  may  cause  undesirable  results  to  occur.  Variability  includes  any  change  in  the 
number  of  students  to  train,  time-to-train,  instructor  availability,  material  availability,  and 
other  supporting  factors. 

Undesirable  effects  may  include:  delayed  time-to-train,  wasted  valuable 
resources,  reduced  morale,  reduced  quality  of  training,  or  an  increase  in  undesirable 
behaviors  as  a  result  of  perceived  production  pressures.  “Wasted  valuable  resources” 
includes  human  capital,  money,  material,  and  time. 

Although  other  sources  of  variability  will  be  discussed,  this  study  will  primarily 
examine  the  cause  and  effect  relationships  resulting  from  variations  in  the  number  of 
students  to  train.  Potential  solutions  are  explored. 
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I. 


INTRODUCTION 


Leaders  within  the  Naval  aviation  training  pipeline  have  the  difficult 
responsibility  of  training  students  on  schedule  when  both  the  resource  availability  and  the 
student  demand  often  changes.  In  the  1990s,  unacceptable  training  delays  within  the 
Naval  aviation  training  pipeline  needed  to  be  addressed.  For  this  purpose,  the  Naval 
Aviation  Production  Process  Improvement  (NAPPI)  began  in  1998  and  ultimately 
resulted  in  a  great  improvement  in  training  time  (Pittman,  2001).  “The  scope  of  the 
NAPPI  effort  comprised  the  entire  "Street-to-Fleet"  training  continuum”  (Pittman,  2001, 
p.  1).  Despite  the  impressive  improvements  by  the  Thomas  Group,  evidence  of  remaining 
inefficiencies  and  bottlenecks  within  the  pipeline  created  a  reason  to  continue  the  search 
for  further  improvements. 

In  2002,  a  flight  training  squadron  was  not  completing  students  within  the  allotted 
time-to-train.  Their  sister  squadron,  which  performed  identical  training,  was  in  a  similar 
predicament.  The  training  air  wing,  which  owns  both  squadrons,  acted  appropriately  by 
asking  the  question:  why  were  both  squadrons  unacceptably  behind  in  student 
production? 

The  primary  factor  identified  as  the  cause  for  diminished  student  production  was 
that  available  resources  were  insufficient  to  handle  the  recent  increase  in  the  number  of 
students  sent  into  each  squadron.  Although  the  “organization”  previously  knew  that  the 
student  loading  would  increase,  the  “organization”  did  not  understand  exactly  how 
student  loading  would  potentially  decrease  each  squadron’s  ability  to  complete  students’ 
training  within  the  allotted  time-to-train. 

Training  resources  may  be  reduced  by  unpredictable  weather,  airframe 
difficulties,  or  even  the  flu  season.  Student  training  demand  may  fluctuate  as  a  result  of 
multiple  factors  including  a  changing  fleet  demand.  How  may  the  planning  process  be 
improved  to  better  predict  or  avoid  training  delays  in  consideration  of  the  complex 
training  environment? 
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A.  BACKGROUND 

In  1998,  the  Navy  instituted  the  NAPPI  project  in  response  to  six  years  of  failure 
to  produce  fleet  squadron  requirements  for  first-tour  aviators  (Pittman,  2001).  The  three- 
year-long  NAPPI  project  was  implemented  to  achieve  the  following  goals:  (1)  reduce 
time-to-train  by  33%;  (2)  increase  the  number  of  pilots  and  NFOs  sent  to  operational 
forces;  and  (3)  install  an  ongoing  management  process.  NAPPI  encompasses  the  entire 
“Street  to  Fleet”  training  concept,  beginning  from  the  new  aviators  commissioning  date 
and  ending  at  the  advent  of  their  first  fleet  squadron  assignment. 

The  efficiency  of  the  Naval  aviation  training  program  declined  because  of  an 
increased  number  of  students  and  a  longer  time-to-train.  The  Navy,  primarily  due  to  the 
personnel  and  manning  decisions,  had  to  reduce  their  force  structure  during  the  years 
following  the  Cold  War  and  Desert  Storm.  In  the  reduction  process,  the  Navy  cut  the 
accessions  of  new  pilots  rather  than  forcing  senior  pilots  into  retirement,  thus  causing  a 
shortage  of  pilots  to  meet  fleet  requirements.  Upon  discovering  this  error  in  force 
structure,  the  Navy  increased  the  number  of  accessions,  causing  a  back  up  in  the  training 
program  as  students  competed  for  training  resources  (Pittman,  2001). 

NAPPI  was  structured  as  a  three-year  project  implemented  to  make  training  more 
efficient.  Multiple  changes  were  made  to  the  existing  process  to  decrease  the  time-to- 
train  by  35  to  40  percent  for  a  maximum  of  30  months  and  optimize  the  use  of  training 
resources.  The  Navy  employed  a  form  of  management,  adopted  from  the  commercial 
sector,  called  Total  Cycle  Time  (TCT).  TCT  concentrated  on  processes,  methods,  culture, 
metrics,  behavior,  and  strategy  to  improve  efficiency  in  the  training  process  instead  of 
increasing  equipment  and  people.  By  identifying  and  removing  barriers,  the  TCT  concept 
changed  the  training  from  several  separate  processes  into  a  program  on  a  single 
continuum  from  commissioning  to  fleet  assignment.  A  standardized  process  and  key 
metrics  package  was  installed  in  order  to  have  a  consistent  measure  across  the  continuum. 
A  management  hierarchy  was  also  put  in  place  to  regulate  and  unify  the  process.  Finally, 
the  Navy  developed  a  coordinated  Flow  Management  Plan  to  link  the  phases  of  the 
training  pipeline  (Pittman,  2001). 
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In  order  to  facilitate  this  increased  coordination,  a  management  structure  needed 
to  be  established.  On  the  highest  level,  the  Naval  Aviator  Production  Team  (NAPT)  was 
formed.  The  goal  of  this  organization  is  to  view  the  overall  training  process  in  order  to 
make  key  decisions  on  process-wide  barriers,  review  performance,  and  coordinate  actions 
throughout  the  training  pipeline.  The  NAPT  meetings  are  held  monthly  via  web  or  video 
teleconference  and  semi-annually  in  person.  The  next  level  down  is  the  Cross-Functional 
Teams  (CFTs),  comprised  of  representatives  from  all  the  commands  involved  in  the 
training  pipeline.  The  CFTs  meet  weekly  to  coordinate  and  reduce  the  time  of  students 
between  the  three  phases  of  the  training  process  (Pittman,  2001).  These  phases  are 
identified  as  the  accession  segment,  the  formal  training  segment,  and  the  Fleet 
Replacement  Squadron  (FRS)  segment. 

In  order  to  evaluate  this  new  system  a  set  of  key  performance  metrics  was  also 
adopted  from  the  commercial  sector  called  Dynamic  Cycle  Time  (DCT)  (Figure  1). 


jyQj  _  Studen tsln T ra in i ng (SIT) or WorklnProgress ( WIP ) 
ProcessingSpeed  (PS) 

WIP  _  BeginningWIP  +  EndingWIP 
~  2 

De  _  InsPerMonth  +  OutsPer Month 

lO  — 

2 

BeginningWIP  +  EndingWIP 

OCT  = _ - _ 

InsPerMonth  +  OutsPerMonth 

2 

ppj  _  Beginning  WIP  +  Ending  WIP 
_ InsPerMonth  +  OutsPerMonth _ 

Figure  1.  DCT  Mathematic  Derivation.  (After:  Thomas  Group,  Inc.,  1997) 

The  WIP  and  PS  in  a  training  squadron  is  constantly  changing,  hence  their  numerical 
values  are  only  an  approximation  based  on  an  average  for  a  reporting  period,  which  is 
usually  a  month  (Thomas  Group,  Inc.,  1997). 
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DCT  is  used  to  evaluate  cycle  time  to  provide  the  NAPT  and  CFTs  with  accurate 
accounts  of  the  time-to-train  newly  selected  pilots  and  NFOs  within  each  phase  of  the 
training  pipeline.  These  new  metrics  are  a  tool  that  decision  makers  can  use  to  examine 
all  phases  of  the  training  cycle  in  order  to  optimize  the  entire  cycle  rather  than  optimizing 
each  individual  part.  Currently,  the  Navy  uses  “Cockpit  Charts”  (Figure  2)  to  display  all 
of  the  metrics  gathered  (Pittman,  2001).  Figure  2  is  an  image  of  “Cockpit  Charts”  as 
displayed  from  the  NAPP  Integrated  Production  Data  Repository  (NIPDR)  website. 


Figure  2.  Cockpit  Charts.  (From:  Training  Air  Wing  6,  2004) 

These  charts  are  organized  in  such  a  way  as  to  facilitate  quick  interpretations  and 
predictions  from  the  data  depicted.  By  evaluating  these  data  the  Navy  should  be  able  to 
assess  the  required  training  time  for  newly  selected  pilots  and  NFOs.  The  charts  display 
the  number  of  students  in  the  training  pipeline  as  well  as  the  use  and  status  of  all  the 
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training  resources.  These  metrics  are  suppose  to  provide  the  NAPT  team  with  enough 
data  that  will  enable  them  to  make  decisions  on  how  to  best  optimize  the  use  of  planes, 
instructors,  and  other  training  resources  within  the  Naval  aviation  training  pipeline. 
Therefore,  the  clogging  effect  generated  by  uninformed  accession  decisions  should  be 
reduced. 

B.  PROBLEM  DEFINITION 

Avoidable  training  delays  exist  within  the  Naval  aviation  training  pipeline.  Delays 
will  result  when  resources  are  insufficient  to  train  the  given  number  of  students. 
Unforeseen  instances  of  resource  insufficiency  may  occur  due  to  the  dynamics  between 
fluctuating  resource  availability  and  the  fluctuating  number  of  students  to  train.  How  may 
planning  be  improved  to  predict  and/or  reduce  training  delays  that  result  from  resource 
constraints? 

C.  PURPOSE 

The  purpose  of  this  study  is  to  explore  methods  for  predicting  training  delays 
which  may  result  from  resource  constraints.  A  prototype  Decision  Support  System  (DSS) 
will  be  designed  to  demonstrate  that  a  predictive  tool  may  allow  for  more  efficient 
planning  and  use  of  training  resources  (capacity)  in  relation  to  fluctuating  student 
loading.  This  web  application  will  produce  a  graphed  projection  of  one  squadron’s  ability 
to  meet  student  training  demand  based  on  the  following: 

1 .  Estimated  future  production  capacity  due  to  limited  resources;  and 

2.  Projected  student  loading. 

In  order  to  accomplish  this  objective  it  will  be  necessary  to  analyze  the  training 
process  from  Aviation  Pre-Flight  Indoctrination  (API)  to  FRS  and  determine  the 
predictive  correlations  between  student  loading,  time-to-train,  and  capacity  limitations. 

D.  SCOPE 

This  study  will  focus  on  a  subset  of  the  overall  Naval  aviation  training  pipeline 
program.  Naval  aviation  training  is  composed  of  two  branches,  pilot  training  and  Naval 
Flight  Officer  (NFO)  training.  NFO  training  is  centrally  located  in  Pensacola,  Florida  at 
Training  Air  Wing  6  (TRAWING  6),  whereas  pilot  training  is  not  located  in  one 
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geographic  area.  Specifically,  this  research  will  be  an  examination  of  the  NFO  training 
branch  (Figure  3).  Figure  3  is  a  diagram  that  illustrates  the  process  flow  for  NFO  training. 


Figure  3.  NFO  Training  Diagram. 

The  basic  NFO  training  program  involves  two  squadrons  at  TRAWING  6. 
Officers  arriving  from  API  are  initially  sent  to  either  Flight  Training  Squadron  (VT)  10  or 
VT  4.  VT  10  and  VT  4  perform  the  same  type  of  training,  Primary  and  Intermediate. 
Some  of  the  students  that  finish  Primary  are  diverted  from  Intermediate  in  order  to  start 
advanced  training  at  Randolph  Air  Force  Base  in  San  Antonio,  Texas.  Upon  completion 
of  Intermediate  training,  officers  are  sent  to  one  of  two  other  types  of  advanced  training 
at  either  VT  86  or  an  Airborne  Early  Warning  (VAW)  Unit.  After  these  training  phases, 
officers  are  assigned  to  a  FRS  and  finally  an  operational  fleet  squadron,  the  end  user 
aviation  community.  This  study  will  use  the  phase  student  training  production  approach 
to  model  the  DSS.  The  purpose  of  a  DSS  solution  would  be  highlighting  the  issue  of 
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numbers  of  students  to  the  squadrons  responsible  for  student  training  prior  to  their 
training  class  start  date.  This  information  is  crucial  to  decision  makers’  ability  to  manage 
student  capacity. 

E.  RESEARCH  QUESTIONS 

This  study  is  centered  on  one  question.  Can  a  web-enabled  database  DSS  provide 
decision  makers  with  predictive  training  pipeline  capacity  threshold  indicators,  so  they 
may  take  preventive  actions  to  minimize  capacity-related  system  inefficiencies?  The 
ability  to  build  upon  an  existing  application  platform  or  develop  a  new  DSS  that  can 
perform  this  function  will  be  the  sole  determinant  of  success  or  failure. 

There  are  supplementary  questions  that  must  be  posed  in  order  to  properly 
construct  this  DSS.  These  questions  are  as  follows: 

1 .  Are  student  loading  fluctuations  demand  or  supply  driven? 

2.  Why  is  level  loading  not  possible? 

3.  Is  there  an  alert  system  currently  in  place  to  help  decision  makers  implement 
preventive  actions? 

4.  Is  it  possible  to  start  students  earlier  to  take  advantage  of  training  resources 
that  would  otherwise  be  wasted? 

5.  Are  resource  limitations  identical  in  each  training  air  wing  throughout  all 
phases  of  training? 

The  above  questions  will  guide  the  development  of  the  proposed  DSS  solution. 

F.  NEED  FOR  THE  STUDY 

The  objective  for  this  proposed  DSS  is  to  aid  decision  makers  in  reducing  training 
delays  caused  by  student  loading  fluctuations.  The  proposed  DSS  would  be  able  to 
predict  under-capacity  and  over-capacity  situations.  It  would  also  allow  for  modification 
of  parameters  to  assist  decision  makers  in  determining  the  best  course  of  action. 

1.  Direct  Benefits 

The  implementation  of  this  DSS  would  improve  the  Naval  aviator  production 
system  in  terms  of  time  and  financial  resources.  Officer  time  exerted  on  attempting  to 
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resolve  production  related  issues  would  be  reduced  using  a  DSS  that  accurately  identifies 
problems.  The  DSS  would  also  reduce  Navy  funding  spent  on  contractor  overtime 
periods  and  officer  pay. 

Contractor  overtime  periods  refer  to  conducting  work  during  a  time  period  that  is 
considered  beyond  the  normal  work  hours  such  as  a  weekend  or  evening.  Some  contracts 
establish  a  baseline  monthly  hourly  usage.  When  usage  goes  above  that  amount,  the  Navy 
pays  some  percentage  above  that  standard  amount.  Maintainers,  civilian  pilots,  and 
simulator  instructors  are  all  paid  overtime  in  this  manner.  Overtime  usage  would  decrease 
because  workload  surges  caused  by  peaks  in  student  loading  fluctuations  would  be 
reduced. 

In  addition,  student  officers  would  spend  less  time  in  the  training  pipeline.  This 
translates  into  officer  pay  funding  savings  due  to  the  reduced  time  required  for  officers  to 
complete  aviation  training.  Hence,  officer  pay  is  being  appropriated  for  time  periods 
actually  spent  training  and  less  for  time  periods  awaiting  training. 

2.  Generic  Application 

The  Literature  Review  chapter  will  show  that  the  need  for  effective  tools  to 
manage  human  resources  is  not  isolated  to  Naval  aviation  training.  Also,  the  complexity 
and  extent  of  a  problem  may  require  the  integration  of  multiple  DSSs.  Therefore,  the 
prototype  DSS  being  developed  in  this  study  has  potential  use  in  other  fields  and  with 
other  DSSs. 

G.  STUDY  OVERVIEW 

The  study’s  purpose  is  to  analyze  the  current  Naval  aviation  training  capacity 
management  system  in  order  to  design  a  prototype  web  application  that  can  provide 
managers  with  the  pertinent  information  to  mitigate  problems  related  to  training  capacity 
inefficiencies.  This  study  will  require  the  development  of  an  automated  tool  that  can 
predict  the  following: 
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1 .  Training  phase  capacity  limitations; 

2.  The  probability  of  on-time  completion  for  students  to  flow  through  the 
training  pipeline  based  on  training  phase  capacity  limits  and  predicted  student 
loading;  and 

3.  The  effects  of  operational  decisions  by  changing  variables  such  as  student 
loading  and  training  phase  capacity. 

Therefore,  the  technologies  that  will  be  best  suited  for  designing  the  prototype  DSS  will 
have  to  be  determined. 
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II.  LITERATURE  REVIEW 


The  problem  cited  in  this  study  is  not  isolated  to  only  the  Naval  aviation 
community.  Comparable  situations  can  be  identified  within  other  branches  of  the  military 
and  the  private  sector.  A  few  of  these  pertinent  studies  are  delineated  in  the  next  two 
sections. 

A.  RELATED  MILITARY  STUDIES 

In  March  of  2000,  Joseph  Grant  conducted  a  study  on  “Minimizing  Time 
Awaiting  Training  [MTAT]  for  Graduates  of  the...”  Marine  Corps  Basic  School  (TBS). 
The  purpose  of  Grant’s  study  was  to  develop  a  desktop  computer  model 

...that  optimally  distributes  military  occupational  specialty  quotas  to  all 
fiscal  year  Basic  School  companies  and  minimizes  the  time  spent  waiting 
by  officers  between  graduation  and  the  start  of  their  occupational  school; 
while  also  providing  maximum  equity  of  opportunity  for  all  officers  to 
seek  any  of  the  twenty-one  military  occupational  specialties  [MOSs] 

(Grant,  2000,  p.  v). 

MTAT  model  runs  exhibited  “a  total  time  savings  ranging  from  a  high  of  forty-five  man 
years,  to  a  low  of  twenty  man  years”  (Grant,  2000). 

The  MTAT  model  was  built  with  the  General  Algebraic  Modeling  System 
Software  (Grant,  2000).  Decision  makers  are  able  to  use  this  model  for  executing  various 
manpower  scenarios  by  changing  the  following  parameters: 

1 .  Total  number  of  TBS  graduates  per  company; 

2.  Graduation  dates  for  TBS  companies; 

3.  Total  yearly  requirements  for  each  MOS; 

4.  Minimum  number  of  Marines  with  specific  MOSs  desired  from  each 
TBS  company; 

5.  Maximum  number  of  Marines  with  specific  MOSs  desired  from  each 
TBS  company; 

6.  MOS  class  start  date;  and 

7.  MOS  class  seat  capacity  (Grant,  2000). 
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Additionally,  the  MTAT  model  employs  parameter  constraint  mechanisms  that 
will  initiate  a  negative  result  once  a  threshold  has  been  exceeded  by  running  a  particular 
scenario.  For  instance, 

...the  model  might  determine  the  need  to  graduate  a  large  number  of 
officers  early  from  TBS  in  order  to  meet  MOS  school  start  dates  and 
reduce  P2T2  [Prisoners,  Patients,  Trainees,  and  Transfers],  If  graduating  a 
large  number  of  officers  early  from  TBS  creates  an  administrative  burden 
on  TBS,  decision  makers  can  quickly  modify  the  model’s  proposed 
solution.  They  can  easily  increase  the  penalty  for  graduating  early  as  well 
as  tighten  the  constraint  on  the  number  of  days  allowed  to  leave  early 
(Grant,  200,  pp.  49-50). 

Thus,  decision  makers  can  determine  the  appropriate  implementation  of  manpower  policy 
by  reviewing  its  impact  using  the  MTAT  computer  model,  which  can  run  a  scenario  in 
two  minutes. 

B.  RELATED  NON-MILITARY  STUDIES 

In  2002,  Pei-Shun  Ho  and  Amy  Trappey  conducted  a  study  to  develop  an 
intelligent  distribution  center  (DC)  human  dispatching  system  for  improving  operational 
time  and  cost  efficiency  in  order  to  meet  low  cost  and  fast  delivery  customer  service 
demands.  This  required  the  integration  of  multiple  DSS  modules.  One  of  these  modules 
was  a  dispatching  algorithm  that  mimicked  the  “...environment  for  assigning  order¬ 
picking  jobs  to  personnel  resource”  (Ho  &  Trappey,  2002,  p.  64).  “In  DC  operations, 
order-picking  often  commands  60  percent  of  a  DC's  labor  force”  (Ho  &  Trappey,  2002,  p. 
71).  Hence,  this  module  is  a  critical  component  to  the  overall  DC  system.  The  order¬ 
picking  process  is  comprised  of  four  major  steps  (Ho  &  Trappey,  2002).  They  are  the 
following: 

1 .  Managing  the  on-line  data; 

2.  Dividing  the  orders  into  order-picking  lists; 

3.  Dispatching  human  resource  to  the  order-picking  lists;  and 

4.  Measuring  worker’s  performance  in  order-picking  processes  (Ho  & 
Trappey,  2002). 
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In  order  to  design  a  system  to  perform  the  above  tasks,  rules  were  established  for 
the  following: 

1 .  Picking-list  dividing; 

2.  Volume  and  weight  distribution; 

3.  Vehicle  assignment;  and 

4.  Worker  versus  (vs.)  workloads  assignment  (Ho  &  Trappey,  2002). 

The  objective  for  this  order-picking  module  output  is  “...to  ensure  all  workers  have 
equivalent  and  adequate  workload...”  (Ho  &  Trappey,  2002,  p.  64).  These  objectives 
were  accomplished  by  instituting  the  following  system  heuristics  for  the  assigning  of 
operators: 

1.  Input  the  basic  volume  that  one  operator  can  pick  each  day,  which 
establishes  the  basic  volume  capacity  per  operator. 

2.  Calculate  total  volume  of  all  orders,  and  divide  total  order  volumes  by 
the  basic  volumes.  Then,  the  required  number  of  operators  is 
approximately  calculated. 

3.  Receive  each  order  volume  one  by  one.  When  the  total  amount  of 
volume  exceeds  the  basic  volume,  the  order  is  still  to  be  assigned  to 
the  current  worker.  However,  the  next  order  is  assigned  to  the  next 
worker  in  line.  Thus,  all  operators’  workload  is  controlled  in  an 
acceptable  level  (Ho  &  Trappey,  2002,  pp.  69-70). 

Another  feature  included  in  this  module  is  an  administrator  capability  that  dynamically 
assigns  replacement  workers  when  individuals  are  absent  (Ho  &  Trappey,  2002). 

There  is  also  a  transportation  module  within  the  DC  system.  This  component  was 
designed  for  utilizing  a  truck  as  the  mode  of  transportation.  The  heuristics  for  this  module 
are  based  on  two  factors,  truck  capacity  and  service  region  (Ho  &  Trappey,  2002).  For 
example, 

If  the  next  order  was  put  on  the  truck  and  the  total  volume  exceeded  the 
limit  of  the  truck,  this  order  would  be  transferred  to  the  other  truck.  In  the 
case  of  an  urgent  situation,  a  mobility  function  is  set  for  backup.  Every 
region  has  a  specific  truck  for  transferring  urgent  orders  only  (Ho  & 
Trappey,  2002,  p.  71). 
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This  study  focused  on  a  manpower-intensive  distribution  center  (Ho  &  Trappey, 
2002).  Business-Process  Reengineering  (BPR)  was  a  key  methodology  used  in  the 
development  of  this  DC  human  dispatching  system.  BPR  requires  an  organization  to 
scrutinize  their  entire  processes,  and  then  derive  a  means  for  improving  the  efficacy  of 
those  institutional  processes.  This  methodology  has  a  direct  correlation  to  determining  the 
appropriate  application  heuristics. 

In  February  1998,  Henderson  wrote  about  Computer  Applications  for  Logistics, 
Engineering,  and  Business  (CALEB)  Technologies  development  of  a  comprehensive 
DSS,  RecoverySuite,  for  Continental  Airlines.  There  are  three  modules  that  comprise  the 
RecoverySuite  DSS.  The  CrewSolver  system  is  one  of  the  three  DSS  modules. 

CrewSolver  is  a  real-time  management  tool  designed  to  optimally  distribute  flight 
crews  during  irregular  operations,  “enabling  rapid  recovery  to  the  original  crew  schedule” 
(Navitaire,  2004).  According  to  Anna  White,  director-crew  systems/planning  at 
Continental,  CrewSolver  was  projected  “to  save  her  airline  $2  million  a  year  by 
optimizing  redeployment  of  flight  crews  when  weather  or  unplanned  events  upset  daily 
operations”  (Henderson,  1998,  p.  102). 

The  CrewSolver  system’s  solutions  are  calculated  to  comply  with — and  as 
part  of  the  solution  process  are  checked  against — government  legalities, 
contract  obligations,  specific  crew  qualifications,  and  company  business 
rules.  The  CrewSolver  system  maintains  a  complete  real-time  view  of 
airline  operations  24/7.  An  in-memory  database  contains  up-to-the-minute 
information  on  cancellations,  diversions,  delays,  equipment  swaps,  crew 
schedules,  and  flight  arrival  and  departure  times.  Similarly,  up-to-date 
information  is  maintained  for  cities  and  stations,  equipment,  legalities,  and 
qualifications.  As  crews  are  disrupted,  the  CrewSolver  system  returns  one 
or  more  low-cost,  least-disruptive  crew  solutions  within  the  parameters 
chosen  (Navitaire,  2004). 
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III.  METHODOLOGY 


The  Business-Process  Reengineering  (BPR)  methodology  was  selected  to  gain 
understanding  of  the  current  process,  identify  beneficial  process  changes  and  potential 
implementations.  The  Spiral  Model  was  selected  for  the  information  technology 
development  approach. 

BPR  is  generally  defined  as  the  analysis  and  design  of  workflows  and  processes 
within  and  between  organizations.  Electronic  (E)-Business  solutions  work  well  in 
geographically  dispersed  organizations.  BPR  for  e-business  was  considered  to  be  a 
potentially  good  match  for  the  geographically  dispersed  Naval  aviation  training  pipeline. 
According  to  Omar  El  Sawy  (2001),  “BPR  for  e-business  involves  rethinking  and 
redesigning  business  processes  at  both  the  enterprise  and  supply  chain  level  to  take 
advantage  of  Internet  connectivity  and  new  ways  of  creating  value”  (p.  7).  In  this  context, 
business  process  refers  to  “a  coordinated  and  logically  sequenced  set  of  work  activities 
and  associated  resources  that  produce  something  of  value  to  a  customer”  (El  Sawy,  2001, 
p.  16).  The  BPR  methodology  provided  the  best  means  for  designing  a  robust  process 
model  for  the  Decision  Support  System  (DSS).  BPR  requires  the  defining  of  an  “as-is” 
process  model,  the  analysis  of  this  model,  and  the  redesign  of  the  “as-is”  model  for  the 
formulation  of  a  “to-be”  model. 

El  Sawy  describes  the  BPR  as  being  achieved  in  three  phases:  (1)  a  scoping 
phase;  (2)  a  modeling,  analysis,  and  redesign  phase;  and  (3)  a  planning  process 
integration  phase.  A  Knowledge- Value- Added  (KVA)  analysis  was  used  within  the 
second  BPR  phase  to  provide  metrics  for  determining  and  ranking  areas  of  improvement. 

The  knowledge -value-added  (KVA)  methodology  addresses  a  need  long 
recognized  by  executives  and  managers  by  showing  how  to  leverage  and 
measure  the  knowledge  resident  in  employees,  information  technology, 
and  core  processes.  KVA  analysis  produces  a  retum-on-knowledge  [ROK] 
ratio  to  estimate  the  value  added  by  given  knowledge  assets  regardless  of 
where  they  are  located.  This  translation  allows  allocation  of  revenue  in 
proportion  to  the  value  added  by  knowledge  as  well  as  the  cost  to  use  that 
knowledge  (Bell  &  Housel,  2001,  p.  91). 
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KVA  recognizes  that  all  processes  implement  a  definable  amount  of  knowledge. 
Knowledge  is  either  implemented  by  a  person  or  a  machine  as  in  for  the  form  of 
software,  for  example.  Embedding  knowledge  into  a  process  has  a  definable  cost  and 
using  the  knowledge  in  a  process  has  a  definable  cost.  The  relative  cost  metrics  which 
result  from  KVA  allow  leaders  to  see  where  valued  knowledge  resides  and  to  then 
consider  how  processes  may  be  improved  to  minimize  cost  by  maximizing  the  knowledge 
invested.  For  aviation  training,  the  existing  processes  were  examined  to  determine  if  there 
were  ways  to  better  use  the  human  capital  by  automating  some  production  related 
functions  being  performed  by  flight  instructors  as  a  part  of  their  collateral  duties. 

The  Spiral  Software  Development  Model  was  selected  because  it  recognizes  that 
requirements  change  during  the  development  process  and  encourages  a  customer-centric 
approach  to  software  design.  According  to  Barry  Boehm  (1988),  the  unique  aspect  of 
Spiral  Software  Development  Modeling  “...is  that  it  creates  a  risk-driven  approach  to  the 
software  process  rather  than  a  primarily  document-driven  or  code-driven  process.  It 
incorporates  many  of  the  strengths  of  other  models  and  resolves  many  of  their 
difficulties”  (p.  61). 

A  standard  cycle  for  Spiral-Modeling  will  begin  with  identifying  the  following: 
(1)  objectives;  (2)  alternative  means  of  implementation;  and  (3)  constraints  (Boehm, 
1988).  The  subsequent  steps  are  the  evaluation  of  “alternatives  relative  to  the  objectives 
and  constraints”  and  “the  formulation  of  a  cost-effective  strategy  for  resolving  the 
sources  of  risk”  (Boehm,  1988,  p.  65).  This  analysis  determines  the  actual  procedural 
development  for  an  application,  which  may  require  an  evolutionary  approach  (i.e., 
prototypes). 
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There  is  a  common  element  that  BPR,  KVA,  and  Spiral-Modeling  share.  All 
require  the  participation  of  the  primary  people  from  the  organization  that  the  process  or 
application  is  being  built  for  use.  This  involvement  ensures  that  all  parties  are  in 
agreement,  which  mitigates  the  design  team  from  going  in  the  wrong  developmental 
direction. 
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IV.  THE  “AS-IS”  MODEL 


A.  CURRENT  SITUATION  DECISION-MAKING  PROCESS 

This  chapter  is  a  general  overview  of  the  current  decision-making  process  related 
to  pilot  and  Naval  Flight  Officer  (NFO)  production.  The  information  provided  in  this 
chapter  was  obtained  through  a  questionnaire  (Appendix  B),  face-to-face  interviews, 
phone  conversations,  and  e-mail  exchanges  with  individuals  who  work  in  production  at 
the  Chief  of  Naval  Air  Training  (CNATRA)  and  Training  Air  Wing  (TRAWING)  6.  The 
current  pilot  and  NFO  production  decision-making  process  is  as  follows: 

1.  The  process  begins  with  the  delivery  of  the  Office  of  the  Chief  of  Naval 
Operations  (OPNAV)  “Fleet  First  Tour  Pilot  and  NFO  Requirements”  document  (Figure 
5).  CNATRA,  the  Aviation  Community  Manager  for  the  Navy,  and  the  Fleet 
Replacement  Squadrons  (FRSs)  use  this  document  to  prepare  the  Integrated  Production 
Plan  (IPP)  for  the  training  air  wings.  This  plan  outlines  the  student  “Planned  Ins”  and 
“Planned  Outs”  for  each  phase  of  Naval  aviation  training  for  the  next  fiscal  year  in  order 
to  meet  the  OPNAV  fleet  requirements.  The  IPP  (Figure  6)  required  student  delivery 
times  for  each  phase  of  training  is  determined  by  subtracting  training  times  and 
accounting  for  real-time  information  from  Aviation  Pre-Flight  Indoctrination  (API). 


N7S23  FLEET  "First  ToU'"  PILOT  AND  NFO  REQUIREMENTS 
OUTS  TO  THE  FLEET -ALL  YEARS 
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Figure  5.  OPNAV  Air  Warfare  Requirements  Document.  (From:  CNATRA, 

2005) 


19 


^^1!  nrn-iiF 


PR&TKdCAl  NFD 


FRS  T«d«INFO 


FRS  TKOCU  NFO 


iWTi»!  in-  uphu 


Figure  6.  IPP  Screenshot.  (From:  CNATRA,  2005) 

2.  Newly  commissioned  Navy  officers  selected  for  aviation  are  first  sent  to 
Introductory  Flight  Screening  (IFS).  IFS  is  used  to  determine  if  the  individuals  selected 
for  Naval  aviation  have  the  “skills  and  attributes  necessary  to  successfully  complete  Navy 
primary  flight  training”  (IFS,  2005). 

3.  Students  who  complete  the  IFS  program  requirements  will  report  to  API, 
and  the  API  production  manager  (API-PM)  asks  the  wings  how  many  bodies  they  will 
need  for  each  class  and  when.  The  API-PM  then  starts  the  number  of  student  NFOs 
(SFO)  and  student  pilots  (SP)  as  he  believes  necessary  to  fulfill  the  delivery 
requirements. 

4.  The  wing  production  managers  (W-PM)  decide  how  many  students  in 
each  class  they  will  need  from  API  based  on  the  FRS  class  start  dates.  They  take  the  FRS 
class  start  dates,  subtract  the  required  training  time,  and  determine  when  and  how  many 
students  will  need  to  begin  training  at  the  training  squadrons  within  the  wing  in  order  to 
meet  the  OPNAV  fleet  requirements.  Once  students  arrive  from  API,  they  wait  until  the 
next  squadron  class  begins  (API  classes  start  each  week,  squadron  classes  start  every  two 
weeks  at  TRAWING  6).  The  wing  monitors  the  squadrons’  delivery  schedule  and  notifies 
them  when  they  are  behind. 
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5.  Training  squadrons  are  assigned  students  by  the  wing.  The  squadron 
production  manager  (S-PM)  then  decides  which  classes  should  be  given  priority  when 
resource  constraints  prevent  student  classes  from  proceeding  as  planned.  Priority  is  often 
based  on  First-In,  First-Out  (FIFO),  but  the  S-PM  controls  the  flow  of  students  through 
the  training  phases  within  the  squadron. 

Figure  7  is  a  depiction  of  the  overall  process  flow  for  Naval  aviation  training. 


Figure  7.  Naval  Aviation  Training  Flow  Diagram. 

Based  upon  one  of  the  author’s  personal  experience  with  NFO  production  issues 
at  Flight  Training  Squadron  (VT)  10  within  TRAWING  6,  the  major  concerns  with  the 
current  system  are: 

1 .  It  does  not  address  wasted  capacity  and  over-capacity  related  issues  due  to 
student  loading  fluctuations. 
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2.  It  does  not  effectively  integrate  horizontal  production-related  decision 
making  across  squadrons. 

3.  It  highlights  problems  and  does  not  offer  solutions. 

4.  The  current  metrics  are  not  suitable  predictors  or  decision  enablers. 

B.  CURRENT  SITUATION  DECISION-MAKING  TOOLS 

There  are  two  primary  production  tools  that  are  used  within  TRAWING  6.  One  is 
the  “Cockpit  Charts”,  which  are  used  throughout  Naval  aviation  training.  The  second,  a 
TRAWING  6  specific  module,  is  called  the  “Fridge  Tool.” 

The  “Cockpit  Charts”  are  an  effective  way  of  seeing  if  enough  students  have  been 
produced  for  a  designated  time  period  and  if  a  squadron  is  on  track  to  produce  enough 
students  for  the  year.  The  difficulty  arises  when  one  is  required  to  interpret  the  data  for 
making  future  decisions.  Although  it  clearly  indicates  past  performance,  it  does  not  offer 
recommendations  for  improving  production.  The  predictive  value  offered  by  this  tool  is 
based  upon  the  reader’s  interpretation  of  data  trends. 

The  “Fridge  Tool”  (Figure  8),  built  on  top  of  the  Microsoft  Excel  application,  is 
used  to  implement  a  “pull”  or  Just-In-Time  (JIT)  production  economic  system.  According 
to  Bonney  (1999),  Lee  stated  that  in  a  “pull”  system  the  following  occurs: 

Activities  at  the  process  station  are  triggered  by  depleted  output  kanban 
stock  at  the  process  stations.  Each  depleted  kanban  [Kanban  is  the 
Japanese  word  for  signal  (The  Hands-On  Group,  2005).]  stock  constitutes 
a  queue  unit  at  the  station.  Before  a  job  can  be  loaded  a  check  is  made  to 
ensure  that  the  precedence  constraint  is  satisfied;  that  is  there  must  be 
sufficient  inventory  in  the  output  kanban  stock  of  the  upstream  processes 
of  that  job.  If  so,  a  draw  is  made  from  the  output  kanban  stock.  Should  this 
cause  the  output  kanban  stock  to  fall  below  the  re-order  level,  the  job  is 
queued  at  that  station  (p.  54). 

Now,  the  main  purpose  of  the  “Fridge  Tool”  is  to  compute  the  number  of  students 
that  start  each  class  for  a  TRAWING  6  training  phase  and  the  number  of  students  that 
start  classes  for  follow-on  training  phases  supplied  by  TRAWING  6.  It  is  based  on  the 
IPP  spreadsheet  data.  In  other  words,  the  IPP  states  the  number  of  first-tour  pilots  and 
NFOs  required  by  the  fleet  and  when  they  have  to  be  completed  with  training  in  order  to 
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arrive  at  their  fleet  billet  on  time.  The  “Fridge  Tool”  recursively  interprets  the  IPP  data  in 
order  to  provide  NFO  training  phase  class  start  dates  and  class  sizes  based  upon 
scheduled  training  times,  projected  training  phase  attrition  rates,  and  user  knowledge 
expertise  of  the  appropriate  number  of  students  to  load  in  each  phase  of  training. 
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Figure  8.  Fridge  Tool.  (From:  TRAWING  6,  2004) 


In  addition  to  the  complexity  of  interpreting  a  large  Excel  spreadsheet  as  shown  in 
Figure  7,  the  “Fridge  Tool”  cannot  predict  training  time  increases.  Therefore,  class  start 
times  are  not  adjusted  for  those  situations  and  some  students  finish  training  late.  These 
are  not  the  only  difficulties  that  exist  with  using  this  tool. 

Also,  the  “Fridge  Tool”  does  not  predict  loading  fluctuations  on  a  scale  that 
correlates  to  a  squadron’s  production  ability.  For  example,  it  would  not  raise  a  flag  if 
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student  loading  into  a  squadron  increased  by  15%  over  a  12-week  period.  It  is  solely  up 
to  the  person  entering  the  data  to  make  that  trend  assessment,  which  depends  on  the 
user’s  experience  and  training. 

C.  CURRENT  SITUATION  DATA  ANALYSIS 

The  initial  training  for  pilots  and  NFOs  is  composed  of  two  phases,  Primary  and 
Intermediate.  Primary  is  the  only  training  phase  that  is  relatively  indistinguishable  across 
the  five  training  air  wings  responsible  for  aviation  training  under  the  Department  of  the 
Navy  (DoN).  Figure  9  plots  the  total  number  of  students  that  started  in  six  classes  of  VT 
10  Primary  Training  over  five  fiscal  years  versus  (vs.)  the  number  of  students  that 
became  held  up  or  pooled  within  VT  10  Primary  Training  for  those  same  fiscal  years, 
also  called  the  Delta-Work-In-Progress  (WIP).  The  six  classes  being  compared  all 
compete  for  the  same  training  resources,  primarily  aircraft  flights. 


Figure  9.  VT  Students  In  vs.  Delta  WIP  Plot. 
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Based  upon  the  graphical  display  (Figure  9)  of  the  VT  10  Primary  Training  Phase 
from  the  data  delineated  in  Appendix  A,  the  following  empirical  observations  were  made: 

1.  Student  loading  fluctuations  contribute  greatly  to  Delta  WIP  fluctuations, 
and  those  fluctuations  appear  to  have  an  annual  pattern.  Graphing  the  same  data  using  a 
monthly  scale  for  the  x-axis  appears  to  show  that  student  loading  peaks  around  February 
(Appendix  A). 

2.  It  appears  once  student  loading  goes  above  40,  training  resources  become 
maxed  out  and  students  will  begin  falling  behind,  meaning  Delta  WIP  increases. 

3.  There  also  exists  periods  where  training  resources  are  wasted  due  to 
having  a  less  than  optimum  number  of  students  in  the  training  pipeline.  Plot  suggests  that 
constant  student  loading  over  time  would  significantly  improve  student  throughput  due  to 
more  efficient  use  of  training  resources. 

In  a  collaborative  effort  between  the  Naval  Postgraduate  School  (NPS)  and  the 
Air  Force  Institute  of  Technology  (AFIT),  Scott  Thatcher,  a  United  States  Air  Force 
(USAF)  Major,  developed  an  Arena  model  that  simulates  the  current  NFO  student 
training  flow  (2005).  Major  Thatcher  was  able  to  use  his  model  to  generate  a  year’s  worth 
of  data  that  could  be  compared  with  data  from  the  actual  NFO  training  system  (2005). 
The  following  graph  (Figure  10)  displays  his  findings: 
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Figure  10.  NFO  Student  Training  Flow.  (From:  Thatcher,  2005) 

The  data  graphed  substantiate  there  is  a  “departure  from  efficient  production 
when  the  system  is  overloaded”  based  on  the  total  time  required  for  student  training 
(Thatcher,  2005).  This  fact  is  depicted  at  the  data  points  “between  36  students  per  class 
and  38  students  per  class,”  which  show  the  “Total  Time  to  Train”  increasing  as  opposed 
to  remaining  constant  (Thatcher,  2005).  This  illustrates  the  impact  of  an  increase  between 
classes  that  is  two  students  per  class  multiplied  by  52  classes  per  year,  which  equates  to 
“a  total  of  104  students  added  to  the  system”  (Thatcher,  2005).  The  statistical  analysis 
conducted  by  Major  Thatcher  supports  the  argument  that  increases  in  time-to-train  are 
due  in  part  to  the  number  of  students  per  class. 

D.  THE  “AS-IS”  PROCESS  MODELS  WITH  KVA  ANALYSIS 

The  “as-is”  process  model  for  Naval  aviator  training  phase  production  capacity 
planning  was  developed  in  essentially  two  steps.  The  first  step  involved  an  initial  draft 
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(Figure  11)  based  on  one  of  the  author’s  experience  as  chief  of  production  at  a  NFO 
training  squadron  in  Pensacola,  Florida  and  phone  conversations  as  well  as  e-mail 
exchanges  between  the  authors  and  the  CNATRA  and  the  TRAWING  6  Production  and 
Planning  Departments. 


Figure  11.  Theoretical  “AS-IS”  Process  Model. 


Figure  1 1  shows  the  basic  data  and  information  flow  that  would  be  necessary  to 
perform  the  following  tasks: 

1 .  Generate  a  report  or  computer  screen  display  for  the  planners  and  support 
elements  involved  in  each  phase  of  aviation  training. 

2.  Transmit  the  future  student  output  data  from  one  phase  of  training  to  those 
responsible  for  follow  on  phases  of  training,  so  next  phase  planners  and  support  elements 
can  determine  whether  they  have  the  capacity  to  train  the  number  of  students  being  sent 
by  the  previous  training  phase. 
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The  second  step  involved  revisions  to  the  initial  “as-is”  process  model  based  on 
face-to-face  interviews  conducted  with  persons  in  the  TRAWING  6  Production  and 
Planning  Office  and  the  TRAWING  6  squadron  operation  offices.  The  information 
obtained  from  these  interviews  led  to  the  design  of  the  two  disjoint  “as-is”  process 
models  (Figures  12  and  13): 


Retrieve:  Current  Generate  Reports  Analysis  of  Reports 

Students 


Figure  12.  Squadron  “AS-IS”  Process  Model. 
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Figures  12  and  13  show  the  following: 

1.  The  training  squadrons  that  fall  under  the  wing  do  not  directly  share 
training  phase  production  capacity  data.  Also,  wing  production  planners  and  operation 
planners  cannot  directly  communicate  with  contractors  that  support  training  due  to 
government  contractual  agreements.  There  is  a  designated  officer  and  civilian 
government  employee  who  are  the  official  liaisons  from  the  wing  to  the  contracted 
supporting  elements. 

2.  The  squadron  training  phase  production  capacity  planning  process  is 
actually  an  ad-hoc  method  that  is  only  performed  under  circumstances  in  which 
concurrent  bad  weather  is  delaying  training. 

3.  The  wing  training  phase  production  capacity  planning  process  is  a 
formalized  procedure  that  occurs  once  a  month. 
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4.  The  number  of  current  students  is  obtained  from  the  Training  Management 
System  version  2  (TMS2)  database  application. 

5.  The  process  of  gathering  the  required  data,  known  as  the  Planning  Factors, 
and  performing  the  necessary  computations  to  determine  the  available  training  resources 
occurs  annually. 

6.  The  required  student  output  data  is  obtained  from  either  the  OPNAV  fleet 
requirements  document  or  the  IPP. 

7.  The  number  of  future  students  is  obtained  from  the  “Fridge  Tool”. 

Now,  a  Knowledge- Value- Added  (KVA)  analysis  of  the  “as-is”  process  models 
will  aid  in  constructing  a  “to  be”  process  model  or  models  by  providing  a  standard 
criteria  for  evaluating  each  of  the  sub-processes  against  one  another.  This  type  of  analysis 
will  single  out  the  sub-process  or  processes  that  have  the  greatest  “value”  and 
dysfunction  within  the  organization  and  vice  versa.  Thereby,  giving  direction  as  to  which 
sub-process  or  processes  require  some  kind  of  change  or  transformation. 

The  Retum-On-Knowledge  (ROK)  ratio,  which  is  used  as  a  means  to  compare  the 
“as-is”  process  model  to  the  “to-be”  process  model,  can  be  derived  by  applying  costs  or 
time  factors  associated  with  each  sub-process.  The  KVA  analysis  for  the  squadron  and 
wing  “as-is”  process  models  applied  time  factors  to  each  of  the  process  models’  sub¬ 
processes.  Associating  time  measures  with  a  specific  sub-process  offered  better  metrics 
than  determining  the  actual  costs  linked  with  a  sub-process  due  to  the  non-disclosure  of 
proprietary  costs,  which  would  have  made  it  difficult  to  accurately  calculate  the  related 
sub-process  cost.  The  data  included  within  the  “as-is”  process  models’  KVA  analysis 
(Figure  14)  were  collected  through  interviews  with  the  individuals  involved  in  the  sub¬ 
processes  at  TRAWING  6.  Then,  the  data  were  used  to  develop  a  KVA  analysis  that  not 
only  considered  NFO  training,  but  pilot  training  as  well.  The  “as-is”  process  models’ 
KVA  analysis  is  as  follows: 
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Figure  14.  KVA  Analysis  for  the  “AS-IS”  Process  Models. 

%  Automated  =  Subjective  Estimation 
Learning  Complexity  =  Level  of  Ranking 

Actual  Learning  Time  (ALT)  =  Knowledge  Contained  in  Process 
Total  Learning  Time  (TLT)  =  ALT  +  (ALT  x  %  Automated) 

NLT  =  100  Units  of  Time 

Total  Revenue  (Normalized)  =  Number  of  Units  Involved  x  People  Involved 
per  Unit  x  Times  Knowledge  Fired  per  Month  x  TLT 

Expense  (Man-Hours  Expended)  =  Number  of  Units  Involved  x  People 
Involved  per  Unit  x  Times  Knowledge  Fired  per  Month  x  Time  to  Complete 
ROK  (Normalized)  =  (Total  Revenue)  h-  (Expense) 


The  KVA  analysis  highlights  several  issues.  At  both  the  squadron  and  wing 
levels,  the  most  difficult  sub-process  is  “Generate  Reports.”  The  second  most  difficult 
sub-process  is  “Analysis  of  Reports.”  At  the  squadron  level,  “Generate  Reports”  has  the 
highest  ALT  value.  At  the  wing  level,  “Analysis  of  Reports”  has  the  highest  ALT  value. 
There  are  other  points  that  could  be  made  from  the  KVA  analysis,  but  it  is  incumbent 
upon  the  analyzer(s)  to  assess  which  problem  areas  to  focus  on.  Although  “Generate 
Reports”  and  “Analysis  of  Reports”  functions  have  relatively  high  ROK  values,  it  is  the 
opinion  of  the  authors  that  the  application  of  information  technology  (IT)  could  have  the 
most  significant  impact  on  these  sub-processes. 
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V.  THE  “TO-BE”  MODEL 


A.  THE  “TO-BE”  MODELS  WITH  KVA  ANALYSIS 

The  derived  “to-be”  process  models  (Figures  15  and  16)  encompass  two 
characteristics,  robust  accuracy  and  communication.  The  “as-is”  process  model  for  the 
wing  and  squadron  had  no  communication  link  between  the  two,  nor  was  there  any 
communication  from  one  training  phase  to  next.  Even  though  the  wing  training  phase 
production  capacity  planning  process  was  a  formalized  one,  the  complexity,  length,  and 
infrequency  of  that  process  did  not  make  it  useful  for  the  training  squadrons.  Therefore,  a 
process  that  implements  a  user  friendly  application  with  minimal  processing  time  should 
be  well  received  by  both  the  wing  and  training  squadrons. 


Figure  15.  Wing  and  Squadron  “TO-BE”  Process  Model. 


Figure  15  removes  the  need  for  the  wing  to  provide  production  capacity  planning 
data  to  the  training  squadrons,  because  both  would  be  granted  access  to  the  Decision 
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Support  System  (DSS)  to  use  as  each  needed.  The  wing  is  concerned  with  long  range 
planning,  whereas  the  training  squadrons  may  need  to  examine  production  capacity  issues 
on  a  weekly  basis.  Now,  the  expansion  of  the  “to-be”  process  model  (Figure  16)  across 
training  phases  includes  the  communication  of  one  phase’s  student  output  number  to  the 
follow  on  training  phase.  This  was  another  missing  piece  to  the  “as-is”  process  models  in 
that  there  was  no  protocol  for  the  sharing  of  student  numbers  from  one  training  phase  to 
the  next.  Such  a  procedure  allows  planners  to  properly  prepare  for  the  incoming 
workload,  and  make  others  aware  of  any  potential  problems  that  may  result  due  to  the 
volume  of  that  workload.  Problems  that  can  be  identified  prior  to  their  occurrence  give  an 
individual  the  opportunity  to  develop  a  solution  that  would  negate  any  occurrence  of  such 
problems. 


Figure  16.  Phase  to  Phase  “TO-BE”  Process  Model. 

Now,  the  “to-be”  Knowledge- Value- Added  (KVA)  analysis  was  only  applied  to 


Training  Air  Wing  (TRAWING)  6,  the  Naval  Flight  Officer  (NFO)  training  system,  since 
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there  may  be  nuances  to  the  geographically  dispersed  pilot  training  program  that  are 
unknown  to  the  authors.  The  “to-be”  process  models’  KVA  analysis  (Figure  17)  is  as 
follows: 
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Figure  17.  KVA  Analysis  for  the  “TO-BE”  Process  Models. 


The  highlighted  columns  and  rows  denote  areas  that  have  changed  from  the  “as- 
is”  KVA  analysis  or  areas  of  importance. 


This  KVA  analysis  cites  the  “as-is”  ROK  ratio  in  the  last  column  next  to  the  “to- 
be”  Retum-On-Knowledge  (ROK)  ratio.  The  difference  between  the  percentages  in  the 
two  columns  indicates  an  improvement  in  the  ROK  ratio  of  the  “to-be”  processes.  It  is 
also  important  to  note  that  the  Actual  Learning  Time  (ALT)  has  not  changed  from  the 
“as-is”  KVA  analysis.  The  reason  the  ALT  remains  constant  is  due  to  the  assumption  that 
the  knowledge  contained  in  a  sub-process  does  not  change,  but  it  can  be  relocated. 
Therefore,  if  a  non-automated  sub-process  is  automated,  the  knowledge  retained  in  the 
individual(s)  is  now  transferred  to  the  automation. 

B.  FIRST  DSS  PROTOTYPE 

The  DSS  prototype  (Appendices  C,  D,  and  E  for  screenshots,  schema,  and 
processing  code  respectively)  forecasts  the  resources  available,  resources  needed  (based 
on  students),  and  resource  actual  usage  (based  on  simulation).  It  determines  the  effects  of 
not  having  enough  resources  (aircraft  or  simulators)  when  they  are  needed.  Data  is 
displayed  in  the  form  of  graphs  labeled  by  phase,  class,  etc.  Only  Flight  Training 
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Squadron  (VT)  4  and  VT  10  are  simulated.  Students  are  transferred  from  one  training 
phase  to  the  next  as  they  complete  each  phase  of  training.  For  a  student  to  progress  on 
time  there  must  be  resources  available  for  that  student  when  he  or  she  needs  the  resources 
as  determined  by  the  syllabus  (DayPlan).  For  example,  when  a  student  in  Primary  begins 
the  flying  stage,  the  “FAM1”  resource  needs  to  be  available  or  the  student  will  not 
progress.  That  resource  is  composed  of,  at  a  minimum,  a  T-6  aircraft.  The  data  required 
to  be  inputted  into  the  application  is  as  follows: 

1 .  Current  and  predicted  student  loading  by  class  and  phase; 

2.  The  syllabus  for  each  phase  to  determine  when  each  student  will  need 
resources  to  complete  an  event;  and 

3.  The  predicted  resource  availability.  (For  example,  how  many  T-6  flights 
are  possible  during  a  given  week?) 

The  purpose  of  the  DSS  prototype  (Appendices  C,  D,  and  E  for  screenshots,  schema,  and 
processing  code  respectively)  is  to  provide  a  forecasting  tool  that  improves  the  decision 
making  process  related  to  NFO  production. 

1.  Requirements 

The  requirements  for  the  prototype  DSS  were  determined  based  upon  interviews 
with  potential  system  users  at  TRAWING  6  and  the  authors'  interpretive  understanding  of 
the  functional  goal  for  the  prototype  DSS  at  the  wing  and  squadron  levels.  Prior  to 
delineating  the  requirements  for  user  input  and  output  the  terminology  for  existing 
TRAWING  6  systems  must  be  clearly  understood. 

This  terminology  is  as  follows: 

1.  145  DayPlan  is  the  student  syllabus  for  Primary  and  Intermediate  phases 
of  training,  which  shows  what  a  student  should  be  doing  in  a  class  and  when. 

2.  X  is  a  variable  used  as  a  general  reference  to  denote  syllabus  course 
events. 

3.  Analysis  05  shows  historically  how  many  student  Xs  were  scheduled  and 
how  many  were  flown. 


36 


4.  Total.xls  shows  how  many  students  were  started  in  and  completed  past 
classes,  present  classes,  and  predicted  future  classes.  It  includes  class  numbers  and  dates. 

5.  X-count  is  one  spreadsheet  showing  how  the  required  student  Xs  can  be 
calculated  by  using  the  number  of  students  in  each  class  and  the  data  from  the  “145  Day 
Plan.xls”  in  a  converted  form. 

The  user  input  for  the  prototype  DSS  is  anticipated  to  be  as  follows: 

1.  Enter  the  syllabus  plan,  such  as  “145  Day  Plan.xls”.  This  is  a  one  time 

entry. 

2.  Enter  the  number  of  students  in  each  class  by  class  number  and  service 
branch  or  student  type,  i.e.,  United  States  Air  Force  (USAF),  United  States  Marine  Corps 
(USMC),  United  States  Navy  (USN),  and  International  Military  Training  (IMT).  This  is  a 
repeated  action. 

3.  Enter  the  predicted  maximum  and  minimum  number  of  flight  Xs  possible 
for  next  6  months.  This  is  a  repeated  action. 

4.  Enter  the  predicted  maximum  and  minimum  number  of  simulator  Xs 
possible  for  next  6  months.  This  is  a  repeated  action. 

5.  Enter  the  number  or  percentage  of  students  required  to  be  transferred  at 
the  end  of  each  phase  and  their  destination.  This  is  a  repeated  action. 

The  output  for  the  prototype  DSS  should  be  graphical  displays  that  will  show  the 
following: 

1 .  Required  student  Xs  vs.  the  maximum  and  minimum  Xs  possible  over  time. 

2.  Required  student  Xs  vs.  the  actual  predicted  student  Xs  over  time. 

3.  Required  student  outs  vs.  the  actual  predicted  student  outs  over  time. 

The  requirements  above  do  not  take  into  consideration  the  size  of  classes  or  the 
number  and  qualifications  of  instructors,  because  these  requirements  apply  to  the  first  of 
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two  prototypes  that  will  be  developed.  Also,  this  model  assumes  the  user  knows  their 
training  resources.  The  second  and  final  prototype  will  include  the  complexity  that  the 
first  prototype  lacks. 

2.  DSS  Website  Storyboard 

Prior  to  physically  designing  any  type  of  Information  Technology  (IT)  system,  it 
is  important  to  articulate  a  concept  about  the  operation  of  the  system  that  is  going  to  be 
built.  The  conceptual  design  provides  a  guide  for  each  person  involved  in  the  actually 
development  of  the  IT  system.  Hence,  the  following  fictional  scenario  outlines  the 
navigational  and  functional  expectations  for  the  “Aviation  Training  Resource  Usage 
Forecaster”  DSS  website.  Now,  the  general  look  and  feel  for  the  website  (Figures  18  and 
19)  will  be  adopted  from  the  existing  Chief  of  Naval  Air  Training  (CNATRA)  website 
located  at  https://www.cnatra.navv.mil/. 

Purpose:  The  squadron  wants  to  know  if  it  will  be  able  to  complete  the  training  of 
students  on  time  given  the  predicted  resource  availability. 

LCDR  Smith  is  the  Operations  Officer  (OPSO)  at  VT  10.  The  first  steps  in 
general  are  as  follows: 


1 .  Get  a  login  identification  (ID). 
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THIS  IS  NOTAN  OFFICIAL  U.S.  GOVERNMENT  WEBSITE. 

THIS  WEBSITE  HAS  BEEN  CREATED  IN  FULLFILLMENT  OF 
THE  REQUIREMENTS  OF  NPS  COURSE  IS4220 

Username 

Password 

ENTER  | 

If  you  require  access  to  this  website,  please  register  here 


Figure  18.  Sample  Login  Web  Page. 


2.  Enter  the  basic  phase  information: 

•  Phase  Name 

•  Syllabus 

•  Syllabus  Resources 
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CNATRA  Home 

Trawing  1 

Trawing  2 

Trawing  4 

Trawing  5 

Trawing  6 

Link  Here 
as  needed 
Link  Here 
Link  Here 
Etc 


Figure  19.  Sample  Content  Web  Page. 

In  addition,  the  phases  receive  students  and  send  students  to  follow  on  phases. 
After  the  general  phase  information  is  entered,  the  following  can  be  entered: 

1 .  The  number  of  available  resources  and  the  resources  availability  period;  and 

2.  The  number  of  current  students  in  each  class. 

At  that  point,  the  website  will  save  the  information  to  a  database,  trigger  the 
processing  of  the  saved  data,  save  the  processed  data  back  into  the  database,  and  then  the 
processed  information  could  be  retrieved  from  the  website.  The  scenario  now  continues 
as  follows: 
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VT  10’s  LCDR  Smith  has  already  been  given  a  user  name  and  password  by  the 
administrator,  as  have  all  OPSOs.  The  OPSO  logs  in.  On  the  next  page,  he  has  to  select 
“Add”  a  phase  since  one  has  not  yet  been  created.  He  enters  the  unit  name  “VT  10”  and 
phase  name  “Primary.” 

He  then  selects  the  type  as  “Real”,  since  it  is  neither  a  “Feeder”  nor  “Exit”. 
“Feeders”  are  just  spreadsheets  that  feed  “Real”  phases.  For  instance,  Aviation  Pre-Flight 
Indoctrination  (API)  is  considered  a  “Feeder”  to  Primary  since  the  web  application  won’t 
track  the  resources,  etc.  for  API.  An  “Exit”  is  simply  a  completion  point  within  the 
training  pipeline  system. 

At  this  point,  he  cannot  select  which  phases  students  come  from  or  go  to  since  no 
other  phases  have  been  added  yet.  Then  he  clicks  on  the  create  button,  which  sends  him 
to  the  page  to  create  a  real  phase  since  that  is  what  he  selected.  The  basis  for  a  phase  is 
the  syllabus.  Since  one  is  not  available  for  selection  because  none  have  been  entered  in, 
he  clicks  on  “Create  one”.  No  syllabus  exist,  therefore  he  must  create  one  from  scratch. 

Since  syllabus  events  are  tied  to  resources,  it  makes  sense  to  (and  he  must)  enter 
the  resources  first.  He  clicks  on  “Add”  (Figure  20)  the  resources.  Each  resource  can  be 
used  by  many  phases.  So,  each  resource  (RSRC)  is  associated  with  a  “Resource  Control.” 
“Resource  Control”  and  name  are  part  of  the  resource  ID.  A  phase  can  select  any 
resource.  He  enters  in  the  basic  resource  information.  He  could  also  enter  in  the  resource 
availability  now,  or  later.  Resource  availability  is  the  quantity  for  a  resource  that  is 
available  per  week.  He  could  click  on  “Resources  Available  per  Time”,  but  chooses  to  do 
that  later. 


Resource  Control 

RSRC  Type 

RSRC  Name 

Wing  6 

Class 

Classroom  Seats 

Add,  Delete 

Wing  6 

Flight 

T-39 

Add,  Delete 

VT  10/4 

Flight 

T-6 

Add,  Delete 

VT  10/4 

Flight 

T-34 

Add,  Delete 

VT  86 

Flight 

T-2 

Add,  Delete 

VT  10/4 

Simulator  (SIM) 

2B37 

Add,  Delete 

VT  10/4 

Simulator 

9X22 

Add,  Delete 

VT  10/4 

Flight 

T-l 

Add,  Delete 

Figure  20.  Add  Resource  Web  Page  Storyboard. 
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So,  now  he  returns  to  syllabus  insert  page  (Figure  21)  in  order  to  create  the 
syllabus.  He  enters  the  syllabus  name  (syllabus  name  is  required).  Then,  he  adds  resource 
related  syllabus  information. 


Day 

Type 

Name 

Control 

Resource 

Usage 

Hours 
of  usage 

Rollback 
Rate  % 

1 

Ground 

BINAV 
Class  1 

Wing  6 

Class 

1 

8 

0 

2 

Ground 

BINAV 
Class  2 

Wing  6 

Class 

1 

8 

0 

3 

Ground 

BINAV 
Class  3 

Wing  6 

Class 

1 

8 

5 

4 

SIM 

CPT-1 

VT  10/4 

2B37 

1 

2 

5 

5 

SIM 

CPT-2 

VT  10/4 

2B37 

1 

2 

8 

6 

Flight 

FAM-1 

VT  10/4 

T-6 

1 

2 

5 

7 

SIM 

NAVSIM 

VT  10/4 

9X22 

1 

2 

2 

8 

Flight 

INAV-1 

VT  10/4 

T-l 

0.5 

2 

5 

Q 

INAV-2 

VT  10/4 

0.5 

9 

7 

10 

INAV-3 

VT  10/4 

1 

2.5 

J 

Figure  21.  Syllabus  Insert  Web  Page  Storyboard. 


Afterwards,  he  can  save  the  syllabus  and  the  basic  phase  information  has  been 
added.  Now,  he  can  go  back  to  the  home  page  and  select  his  phase.  From  there,  he  can 
enter  the  estimated  usage  per  week  of  each  resource  and  the  number  of  students  in  the 
squadron.  He  could  then  run  the  simulation  and  produce  the  graphs.  At  this  point,  since 
there  is  no  “Feeder”  (inputting  new  students)  all  of  the  students  would  move  out  of  the 
phase  and  would  go  nowhere,  (since  the  next  phase  has  not  been  created  and  associated 
with  other  phases) 

3.  Prototype  I  DSS  Demonstration  Feedback 

“An  important  feature  of  the  Spiral  Model  is  that  each  cycle  is  completed  by  a 
review  involving  the  primary  people  or  organizations  concerned  with  the  product” 
(Boehm,  1998,  p.  65).  On  March  22,  2005,  at  1100  Pacific  Standard  Time,  a  video 
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teleconference  (VTC)  was  conducted  between  Naval  Postgraduate  School  (NPS)  and 
TRAWING  6  for  the  purposes  of  demonstrating  the  “Aviation  Training  Resource  Usage 
Forecaster”  website  (http://131.12Q.176.69/wbrb/prototype  l/index.asp),  the  Prototype  I 
DSS,  and  having  a  dialogue  with  one  of  the  potential  product  customers.  Viewing  the 
demonstration  from  TRAWING  6  was  CDR  King,  the  Production  and  Planning  Officer. 

The  initial  comments  received  from  the  VTC  with  CDR  King  were  all  pertaining 
to  the  Prototype  I  DSS  functional  performance.  CDR  King’s  first  responses  were  on  the 
topic  of  data  display.  After  displaying  and  explaining  the  third  optional  graph  (see 
Appendix  C)  that  can  be  generated  from  the  “FORECASTED  GRAPHS”  hyperlink  web 
page,  King  remarked  that  “A  line  and  point  graph  indicates”  a  relationship  between 
plotted  points  over  a  time  period,  but  in  actuality  each  point  is  independent  from  one 
another  based  on  the  class  number  labeling  of  the  x-axis  and  the  description  given  of  the 
data  used  to  produce  the  graph.  “A  bar  graph  might”  be  a  better  representation  of  the 
data. 

The  other  functional  performance  comments  provided  from  the  VTC  with  CDR 
King  were  in  response  to  questions  posed  by  the  demonstration  presenter,  one  of  the 
authors.  The  questions  and  responses  were  as  follows: 

1.  Question:  Would  this  prototype  be  helpful  in  determining  how  many 
students  each  training  phase  can  produce  in  the  required  time-to-train,  considering 
resource  constraints? 

Response  (paraphrased):  The  prototype  is  useful  for  showing  whether  the  NFO 
training  pipeline  is  capacity  constrained,  but  it  is  not  useful  for  managing,  tracking,  and 
predicting  the  day-to-day  flow  of  students.  The  prototype  does  show  the  effects  of 
specific  capacity  related  decisions. 

2.  Question:  Would  this  prototype  be  helpful  in  determining  how  many 
students  to  send  to  follow  on  training  phases? 

Response:  No. 
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3.  Question:  Would  this  prototype  be  helpful  in  determining  future  resource 
requirements? 

Response:  Yes. 

4.  Question:  In  order  to  make  the  above  decisions,  how  far  out  does  the 
forecast  need  to  project? 

Response  (paraphrased):  It  depends  on  the  organizational  level,  wing  vs.  training 
squadron,  or  the  phases  of  training.  The  wing  needs  to  be  able  to  generate  an  1 8-month 
forecast.  If  one  is  examining  NFO  phases  of  training,  then  a  four-month  forecast  is 
required  from  the  start  of  Primary  through  the  start  of  advanced  training  at  Randolph,  and 
a  eight-month  forecast  is  required  from  the  start  of  Primary  to  the  start  of  advanced 
training  at  Airborne  Early  Warning  Unit  (VAW)  120. 

C.  PLANNED  ENHANCMENTS  FOR  DSS  PROTOTYPE  II 

The  enhancements  to  be  made  from  Prototype  I  to  Prototype  II  (Figure  22)  of  the 
DSS  is  focused  on  incorporating  additional  data  parameters  to  be  factored  into  the 
application  processing  that  produces  the  data  output  for  user  graphical  displays. 
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Figure  22.  Prototype  I  Processing  Data  vs.  Prototype  II  Processing  Data 

Diagram. 

The  shaded  objects  in  Figure  22  delineate  the  data  that  is  entered  and  processed  for  DSS 
Prototype  I.  The  non-shaded  objects  are  the  data  parameters  to  be  added  for  user  input 
and  application  processing  for  DSS  Prototype  II.  These  additional  data  parameters  will 
improve  the  data  output  utility  because  more  know  variables  that  can  impact  the 
decisions  made  within  the  Naval  aviation  training  system  environment  will  have  been 
analyzed  and  assessed  by  the  DSS.  The  reason  for  not  including  all  these  data  parameters 
in  DSS  Prototype  I  is  the  authors’  software  development  view  that  it  was  better  to 
produce  an  initial  prototype  for  user  evaluation  than  to  spend  too  much  time  on  the 
programming  for  a  final  prototype  without  allowing  for  any  interim  time  period  so  the 
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users  could  give  feedback  on  the  development  direction  for  the  final  DSS  prototype.  This 
process  replicates  the  Spiral  Software  Development  Model,  but  more  importantly  it  is  the 
authors’  opinion  that  the  user  feedback  from  the  first  prototype  will  contribute  greatly  to 
the  quality  for  the  final  DSS  prototype. 

D.  FINAL  DSS  PROTOTYPE 

Realizing  the  complexity  and  the  desired  performance  end  state  for  Prototype  II, 
the  authors  thought  it  was  worthwhile  to  examine  the  application  of  a  Commercial-Off- 
The  Shelf  (COTS)  solution.  It  is  the  authors’  opinion  that  the  most  suitable  category  of 
software  to  evaluate  as  a  potential  remedy  for  the  problem  involved  in  this  study  would 
be  Enterprise  Resource  Planning  (ERP)  software.  “ERP  software  systems  have  focused 
on  internal  process  integration  of  traditional  functions,  such  as  sales,  production,  and 
inventory  management”  (Kelle  &  Akbulut,  2005,  p.  41). 

1.  Refining  the  Requirements 

The  requirements  for  a  DSS  were  refined  based  on  feedback  received  from 
demonstrations  given  at  CNATRA  and  TRAWING  6.  These  onsite  visits  included  one- 
on-one  interviews  with  potential  system  users.  Each  interviewee  was  presented  with  a 
survey  (Appendices  F  and  G)  designed  to  determine  the  type  of  information  that  would 
be  useful  for  the  DSS  to  provide  and  whether  that  same  type  of  information  was  already 
available  from  another  source.  The  persons  interviewed  also  provided  feedback  on  how 
best  to  present  the  data  output  generated  from  the  DSS. 

Figures  23  and  24  display  the  data  collected  from  the  Likert  Scale  portions  of  the 
surveys  (Appendices  F  and  G)  conducted  at  CNATRA  and  TRAWING  6.  The  graphed 
data  is  configured  such  that  the  x-axis  corresponds  to  a  specific  survey  participant  and  the 
y-axis  corresponds  to  the  Likert  Scale  as  follows: 

1 .  Strongly  Disagree=l ; 

2.  Disagree=2; 

3.  Not  Sure=3; 

4.  Agree=4; 

5.  Strongly  Agree=5;  and 
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6.  No  Response=0. 

This  data  shows  the  number  of  potential  system  users  that  agree  or  disagree  with  the 
survey-proposed  information  to  be  obtainable  from  a  DSS’s  data  output.  This  collected 
data  was  essential  for  refining  the  nature  of  the  information  content  that  users  would  be 
extracting  from  the  DSS’s  data  output. 
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Retirements  Survey  Part  I:  Question  1 
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Figure  23.  TRAWING  6  Survey  Results. 
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Requirements  Sur^y  I  Part  I:  Queslion  1 
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Figure  24.  CNATRA  Survey  Results. 

Figures  25  and  26  show  the  data  collected  from  the  “No”,  “Not  Sure”,  and  “Yes” 
portions  of  the  surveys  (Appendices  F  and  G)  conducted  at  CNATRA  and  TRAWING  6. 
The  graphed  data  is  configured  such  that  the  x-axis  corresponds  to  a  specific  survey 
participant  and  the  y-axis  corresponds  to  the  survey  responses  as  follows: 

1.  No  =1; 

2.  Not  Sure=2; 

3.  Yes=3;  and 
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4.  No  Response=0. 
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Figure  25.  TRAWING  6  Survey  Results. 
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Re qi_ ir e m  ents  Suvey  II  Part  II  Ques:ion  1 
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Figure  26.  CNATRA  Survey  Results. 

These  data  show  whether  or  not  the  proposed  information  to  be  provided  from  a  DSS  is 
already  available  to  potential  system  users.  Now,  Figure  27  shows  the  myriad  of  sources 
that  CNATRA  production  analysts  and  decision  makers  must  use  in  order  to  process 
and/or  retrieve  the  data  necessary  to  obtain  the  information  proposed  for  extraction  from 
the  DSS’s  data  output.  These  data  show  that  at  this  time  there  is  no  one  application  that 
can  provide  all  the  information  discussed  in  the  CNATRA  survey.  The  fact  that  this 
situation  exists  demonstrates  there  is  a  need  for  a  standardized  DSS  that  can  provide  data 
output  which  is  flexible  enough  to  serve  multiple  user  information  needs.  This  means  that 
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the  presentation  or  display  of  data  based  on  the  data  output  from  the  processed  data  must 
have  the  ability  to  be  adjusted  by  the  user  in  order  to  suit  whatever  the  user  thinks  is  the 
best  representation  of  the  processed  data  output. 
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Figure  27.  CNATRA  Data  Sources. 
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2.  Implementation  Considerations 

Identifying  the  right  IT  solution  to  enhance  an  organization’s  competitive 
advantage  is  a  difficult  decision  to  make.  To  select  an  IT  solution  for  an  organization 
under  the  authority  of  the  Department  of  the  Navy  (DoN),  there  are  three  key  questions 
that  need  to  be  answered  prior  to  going  forward  with  the  implementation  of  a  new  IT 
system.  The  questions  to  be  addressed  are  as  follows: 

1.  Does  the  selected  IT  solution  achieve  the  DoN  Chief  Information  Officer’s 
(CIO’s)  strategic  objectives  for  IT  systems? 

2.  Does  the  organization’s  internal,  interface,  and  external  business  processes 
properly  align  with  the  selected  IT  solution? 

3.  Does  the  selected  IT  solution  originate  from  a  viable  company? 

According  to  the  DoN  Information  Management  and  Information  Technology 
(IM/IT)  Strategic  Plan,  FY  2004-2005,  the  Navy  and  Marine  Corps  vision  is  “A  joint  net- 
centric  environment  that  delivers  knowledge  dominance  to  the  Naval  warfighting  team” 
(McArthur,  Thomas,  &  Wennergren,  p.  5).  One  goal  that  supports  the  DoN  IM/IT 
strategic  vision  is  an  objective  from  the  Chief  of  Naval  Operations’  (CNO)  2004 
FORCEnet  Guidance,  which  directs  the  Navy  to  “...investigate  enterprise  solutions  that 
will  exploit  the  power  of  the  web  and  improve  our  productivity  and  return  on  investment” 
(McArthur,  Thomas,  &  Wennergren,  p.  10).  A  program  established  to  facilitate  this  goal 
is  the  Navy  Shore-Based  Oracle  Database  Enterprise  License  Agreement.  “This 
milestone  agreement  provided  the  Navy  shore -based  organizations,  including  active  duty, 
reserve,  civil  service,  and  support  contractor  personnel,  the  right  to  use  the  Oracle 
database  family  of  products”  (McArthur,  Thomas,  &  Wennergren,  p.  1 1). 

Now,  a  prototype  application  only  provides  an  executable  version  of  the  last 
known  understanding  of  the  user  requirements  for  a  potential  software  platform.  Also,  the 
term  prototype  implies  a  system  not  ready  for  full  implementation.  Thus,  by  shifting  the 
direction  of  this  study  from  delivering  a  prototype  application  to  delivering  an  evaluation 
of  a  COTS  ERP  application  from  “the  Oracle  database  family  of  products”,  the  study  is 
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aligned  with  the  IM/IT  strategic  vision  for  the  DON  and  has  the  potential  of  providing 
CNATRA  with  a  real  implemental  IT  solution  (McArthur,  Thomas,  &  Wennergren,  p. 
11). 


The  ERP  software  solution  is  an  implementation  of  “industry  best-practices” 
(Nah,  Tan,  and  Teh,  2004,  p.  41).  Davenport  (1998,  p.  123)  stated,  according  to  Nah, 
Tan,  and  Teh  (2004),  that  the  ERP  software  represents 

a  single  comprehensive  database,  which  collects  data  from  and  feeds  data 
into  modular  applications  supporting  virtually  all  of  a  company's  business 
activities-across  functions,  across  business  units,  across  the  world  (p.  33). 

Nah,  Tan,  and  Teh  (2004)  translated  the  above  statement  to  convey  the  following: 

In  other  words,  the  information  associated  with  individual  modules  of 
ERP  software  is  stored  in  a  central  database  so  that  transactions  or  changes 
taking  place  in  one  module  will  automatically  "trigger"  related  changes  in 
other  modules,  and  multiple  departments  throughout  the  organization  can 
access  the  same  data  (p.  33). 

Thus,  an  institution  cannot  expect  to  improve  its  organization  or  flow  of  information  by 
integrating  business  processes  that  do  not  synchronize  with  the  capabilities  of  their 
selected  ERP  software  solution.  According  to  Calogero  (2000), 

At  the  root  of  many  ERP  problems  lies  one  overlooked  but  critical  step: 
new  business  processes  must  be  established,  thought  through,  and 
implemented  before  software  tools  are  selected,  purchased,  and  rolled  out. 

. .  .the  success  of  an  ERP  implementation  is  gauged  by  its  ability  to  align 
IT  and  business  management  objectives,  demanding  program  management 
skills  and  a  refined  process  for  success.  Organizations  too  often  ignore  the 
need  to  define  an  optimal  process  and  then  use  the  technology  as  an 
enabler  for  the  process.  In  too  many  instances,  organizations  either  try  to 
adopt  a  process  that  is  inherent  in  the  ERP  solution,  even  if  it  does  not  fit 
their  business  requirements,  or  they  try  to  shoehorn  their  legacy  processes 
into  a  software  package  that  is  not  designed  to  support  their  processes.  In 
both  cases,  they  sub-optimize  the  capabilities  in  the  technology  and  don't 
take  advantage  of  the  opportunity  to  streamline  their  business  process  -  the 
entire  point  of  technology  implementations  (p.  8  &  9). 

Also,  an  organization  considering  the  implementation  of  a  new  IT  system  needs  to 
assess  the  financially  stability  of  their  IT  solution  provider.  The  Coast  Guard  spent  $24 
million  “...to  install  the  Human  Resource  (HR)  Connect  system,  a  custom  version  of  the 
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HR  Management  System  from  PeopleSoft  Incorporated  (Inc.)  of  Pleasanton,  California” 
(Mosquera,  2005).  Then  on  December  13,  2004,  after  18  months  of  resistance, 
PeopleSoft  Inc.  agreed  to  be  acquired  by  their  rival,  Oracle  Corporation  (Corp.),  for  $10.3 
billion  (Bank,  2004).  “Now  PeopleSoft  customers”,  like  the  Coast  Guard,  are  “worried 
that  they  may  soon  have  to  switch  software  —  a  time-consuming  and  expensive  process 
(Bank,  2004,  p.  A.  1).  According  to  Banks  (2004)  of  the  Wall  Street  Journal  (WSJ),  prior 
to  Oracle’s  acquisition  of  PeopleSoft  the  global  market  share  breakdown  for  the  top  five 
ERP  software  providers  was  as  follows: 

1.  20.0%  belonged  to  SAP  [Systeme,  Anwendungen,  Produkte  in  der 
Datenverarbeitung  -  German  for  Systems,  Applications  and  Products  in  Data  Processing 
(G.  Cook,  IS-403 1  lecture,  Spring  2005)] 

2.  6.9%  belonged  to  PeopleSoft 

3.  5.5%  belonged  to  Oracle 

4.  2.6%  belonged  to  Microsoft 

5.  2.3%  belonged  to  Sage  Group 

The  percentages  above  show  that  even  “a  combined  Oracle-PeopleSoft  would  still  trail 
Germany’s  SAP”  as  a  provider  of  ERP  software  (Bank,  2004,  p.  A.  1). 

Beyond  Oracle’s  acquisition  of  PeopleSoft,  it  most  recently  acquired  Retek  Inc., 
“a  retail-industry  software  maker”,  on  March  22,  2005  for  $650  million  (Hamm,  2005,  p. 
42).  These  actions  have  placed  Oracle  in  a  head  to  head  battle  with  SAP  over  “...the  $47 
billion  market  for  corporate  applications  software”  (Hamm,  2005,  p.  42).  According  to 
Hamm  (2005)  of  Business  Week, 

By  picking  a  fight  with  SAP,  though,  Ellison  [Oracle  Chief  Executive]  is 
taking  on  a  heavyweight  that's  heavily  favored  to  punch  his  lights  out  in 
the  applications  market.  With  26,000  corporate  customers  worldwide  and 
a  broad  suite  of  products,  SAP  has  become  the  gold  standard  for  corporate 
applications.  Goldman,  Sachs  &  Co.  expects  that  among  the  top  four 
players,  SAP's  share  of  software  license  revenues  will  vault  from  59%  in 
2003  to  70%  this  year.  Meanwhile,  the  firm  expects  Oracle's  share  (with 
PeopleSoft  included)  to  fall  from  30%  to  20%.  "There  will  be  a  lot  of 
marketing  rhetoric,  but  at  the  end  of  the  day,  SAP  has  such  momentum 
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that  Oracle  won't  be  able  to  dislodge  them,"  says  Goldman  analyst  Richard 
G.  Sherlund.  SAP  has  definitely  gone  on  the  offensive.  Before  the  ink  had 
dried  on  the  PeopleSoft  merger,  SAP  began  tempting  PeopleSoft 
customers  with  a  75%  discount  for  switching  over.  Last  year,  the  33-year- 
old  German  company  lured  several  former  Oracle  customers,  including 
PepsiCo  Inc.  How  the  two  rivals  perform  in  the  coming  year  will  probably 
decide  the  outcome.  The  technical  challenges  are  huge,  and  either  side 
could  stumble.  But  the  most  intense  pressure  is  on  Ellison.  He  has  set  his 
sights  on  SAP  before,  and  not  much  came  of  it.  Now  he's  trying  again,  and 
the  stakes  are  higher  than  ever  (p.  42). 

This  discussion  should  bring  to  light  the  gravity  of  the  issues  that  have  to  be 
addressed  when  a  DoN  organization  embarks  on  the  quest  to  identify,  acquire,  and  install 
a  new  IT  system.  These  issues  are  not  trivial  and  if  not  dealt  with  appropriately  can  have 
detrimental  long  term  effects  on  an  organization.  Despite  all  of  these  challenging  issues, 
the  search  for  the  right  IT  solution  can  be  successfully  managed  and  accomplished. 

3.  ERP  Software  Products  Evaluation 

This  chapter  includes  a  summary  evaluation  based  on  publicly  available  product 
information  and  company  representatives  of  ERP  software  providers.  The  products 
sought  were  ones  which  met  the  criteria  defined  in  Chapter  VB.  The  included  information 
is  used  only  as  a  sample  of  available  of  ERP  solutions  and  is  not  intended  to  substitute  for 
a  formally  funded  evaluation  process.  Also,  it  is  not  intended  to  promote  one  company 
over  another. 


a.  Open  Source  Solutions 

Open  source  solutions  initially  appeared  to  be  attractive  due  to  their  low 
cost.  Upon  further  examination,  the  available  open  source  products  would  require  a  great 
deal  of  costly  modification  and  support.  Because  of  the  high  costs,  minimal  existing 
customer  support,  and  little  track  record,  open-source  solutions  are  not  considered  to  be  a 
suitable  solution.  However,  open-source  may  be  a  viable  option  when  the  available 
technologies  mature  and  are  proven.  Examples  of  open  source  solutions  may  be  found  at 
http://www.erp5.org./. 

b.  Commercial  Solutions 

Numerous  potential  commercial  solutions  were  found.  However,  only  a 
handful  of  suitable  products  from  viable  companies  were  identified.  Oracle  and  SAP 
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were  companies  which  were  consider  financially  viable,  offered  potential  solutions,  and 
have  a  working  history  with  the  DON. 

Oracle,  the  number  two  ERP  provider  according  to  WSJ,  is  currently 
working  with  NAVSEA  to  provide  ship  maintenance  scheduling  solution.  In  addition  to 
custom  solutions,  Oracle  markets  an  existing  product  called,  “Advanced  Supply  Chain 
Planning.”  It  claims  to  “perform  simultaneous  material  and  capacity  planning  across 
multiple  facilities  and  time  horizons”  “...run  holistic  plans  that  span  long  term  aggregate 
planning  to  short  term  detailed  schedules...”  (Oracle  Corporation,  2005,  p.  1  &  2).  Most 
importantly,  it  claims  to  help,  “...to  create  feasible  plans  that  take  into  account  your 
resource  and  material  restraints”  (Oracle  Corporation,  2005,  p.  3).  It  also  allows  multiple 
planners  to  perform  simulations  (Oracle  Corporation,  2005).  The  claimed  functionality 
appears  to  fulfill  the  requirements  needed  by  CNATRA. 

SAP  offers  a  product  called,  “SAP  Manufacturing”.  SAP  claims  this 
product  identifies  changes  in  demand  and  supply  and  allows  for  rapid  response  to  new 
customer  requirements. 

SAP  Manufacturing  gives  discrete  and  process  manufacturers 
functionality  to: 

-Coordinate  operations  with  partners  and  suppliers 

-Detect  and  resolve  exceptions  and  performance  deviation  in  real  time  and 
at  low  cost 

-Institutionalize  Lean  and  Six  Sigma  processes  and  monitor  production  to 
drive  continuous  improvement 

-Comply  with  environmental,  health,  and  safety  standards 

-Improve  employee  productivity  and  create  a  high-quality  work 
environment 

With  SAP  Manufacturing,  your  management  and  production  departments 
gain  real-time  visibility  into  key  data  —  enabling  them  to  act  quickly. 
Managers  can  document,  track,  and  interpret  quality  and  performance 
using  rich  analytics  capabilities.  Production  teams  can  leverage  role-based 
applications  for  plant  managers,  production  supervisors,  maintenance 
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supervisors,  and  quality  inspectors  to  detect  and  respond  rapidly  to 
exceptions  and  variances  —  and  deliver  superior  performance  (SAP 
Manufacturing). 


c.  Assessment 

Oracle  and  SAP  each  could  likely  provide  a  beneficial  solution.  A  more 
thorough  analysis  would  require  official  backing  by  a  higher  Navy  authority  to  grant  the 
time  and  resources  needed  to  determine  the  best  solution  and  provider  for  a  CNATRA 
ERP  implementation. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


Command  effectiveness  increases  when  its  activities  are  closely  aligned  to 
mission  objectives.  A  mission  can  be  described  with  two  often  conflicting  purposes:  (1) 
primary— accomplish  the  task;  and  (2)  secondary— use  minimal  resources.  As  the  United 
States  moves  to  reduce  military  costs  by  reducing  military  resources,  commands  may  find 
it  more  difficult  to  “accomplish  the  task”  without  implementing  more  effective  and 
efficient  methods  for  resources  allocation.  Decision  Support  Systems  (DSSs)  can 
improve  command  effectiveness  by  providing  information  to  better  “accomplish  the  task” 
and/or  decrease  the  resources  required. 

A.  STUDY  RESULTS 

This  section  will  address  the  questions  posed  in  Chapter  IE.  The  primary  question 
for  this  study  is:  Can  a  web-enabled  database  DSS  provide  decision  makers  with 
predictive  training  pipeline  capacity  threshold  indicators,  so  they  may  take  preventive 
actions  to  minimize  capacity-related  system  inefficiencies?  The  research  results  indicate 
the  answer  to  this  question  to  be  yes.  An  application  that  illustrates  cause  and  effect 
activity  relationships  has  the  ability  to  show  possible  outcomes  based  on  the  designed 
data  input  parameters;  though,  it  is  difficult  to  devise  an  application  that  generates  a  data 
output  presentation  which  meets  every  user’s  desires.  Thus,  it  is  important  for  a  DSS  to 
have  a  feature  that  either  allows  the  user  to  adjust  the  presentation  of  the  generated  data 
output  or  allows  the  user  to  export  the  generated  data  output  in  order  to  adjust  its 
presentation  within  another  application  of  their  own  choosing. 

Now,  the  supplementary  questions  posed  in  order  to  properly  construct  the  DSS 
were  as  follows: 

1.  Are  student  loading  fluctuations  demand  or  supply  driven?  Research 
results  reveal:  Student  loading  fluctuations  are  primarily  demand  driven.  The  bulk  of 
bodies  that  supply  the  pilot  and  Naval  Flight  Officer  (NFO)  training  pipeline  are 
generated  in  the  May  timeframe,  which  does  not  change  from  year  to  year;  therefore, 
student  loading  is  minimally  affected  by  variation  in  the  timing  of  supply.  Instead,  the 
limited  number  of  pilot  and  NFO  billets  at  the  Fleet  Replacement  Squadron  (FRS)  creates 
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the  demand  within  the  Naval  aviation  training  pipeline.  The  availability  of  FRS  billets 
drives  the  number  of  students  that  are  started  within  the  training  pipeline  and  the  date 
students  start  training;  whereas,  the  number  of  students  inserted  into  the  training  pipeline 
by  the  United  States  Air  Force  (USAF),  the  United  States  Marine  Corps  (USMC),  the 
Flight  Surgeon  program,  and  the  International  Military  Training  (IMT)  program  are  based 
on  a  supply  driven  system.  Their  students  can  arrive  at  unpredictable  times,  but  they  are 
expected  to  complete  training  at  a  standard  rate. 

2.  Why  is  level  loading  not  possible?  Research  results  reveal:  Level  loading 

is  technically  possible.  However,  the  rationale  for  instituting  a  level  loaded  system  would 
have  to  justify  the  potential  side  effects  of  early  trainee  finishers  creating  a  pilot  and  NFO 
inventory  surplus,  which  is  an  added  cost  to  the  taxpayers.  Politically,  the  concept  is  a 
difficult  sell  because  the  Just-In-Time  (JIT)  inventory  methodology  has  been  ingrained 
into  the  social  culture. 

3.  Is  there  an  alert  system  currently  in  place  to  help  decision  makers 
implement  preventive  actions?  Research  results  reveal:  There  is  no  standardized  tool  or 
application  across  all  levels  of  the  Naval  aviation  training  organizational  structure  that 
acts  as  an  alert  system  for  the  purpose  of  enabling  decision  makers  to  take  preventive 
actions. 

4.  Is  it  possible  to  start  students  earlier  to  take  advantage  of  training 
resources  that  would  otherwise  be  wasted?  Research  results  reveal:  Yes,  but  there  seems 
to  be  no  agreement  for  a  policy  that  condones  the  pooling  of  first  tour  pilots  and  NFOs 
beyond  the  training  prescribed  entitlement  periods.  An  entitlement  period  in  this  context 
refers  to  set  time  allotments  between  phases  of  training  that  students  are  given  to 
transition,  which  may  include  leave,  a  Permanent  Change  of  Station  (PCS),  etc. 

5.  Are  resource  limitations  identical  in  each  training  air  wing  throughout  all 
phases  of  training?  Research  results  reveal:  No. 

B.  AREAS  FOR  FURTHER  RESEARCH 

As  this  study  comes  to  a  close,  it  is  evident  that  some  progress  was  made  in 
showing  a  means  to  aid  in  the  management  of  capacity  issues  related  to  the  Naval 
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aviation  training  pipeline.  It  is  also  clear  that  more  work  needs  to  be  done  in  order  to 
improve  the  overall  Naval  aviator  production  system.  This  study  is  just  one  step  in 
several  more  that  need  to  be  taken  in  order  to  transform  the  Navy’s  first  tour  pilot  and 
NFO  production  into  a  more  efficient  system  than  it  is  today. 

1.  Properly  Linking  Requirements  to  Production  Capacity 

The  driving  factor  behind  the  capacity  issue  in  this  study  has  to  do  with  the 
number  of  students  sent  into  the  Naval  aviation  training  pipeline.  The  Office  of  the  Chief 
of  Naval  Operations  (OPNAV)  N782B  determines  these  requirements.  According  to 
Christopher  Munsey  (2005)  of  the  Navy  Times,  the  active-duty  Navy  will  have  an  excess 
of  240  to  260  aviators  “over  this  fiscal  year  and  next”  (p.  16).  This  situation  is  due  in  part 
to  “the  five-year  phaseout  of  ten  S-3B  Viking  squadrons,  and  the  gradual  elimination  of 
the  F-14  Tomcat”  (Munsey,  2005).  The  central  cause  for  this  surplus  of  active-duty  Naval 
aviators  was  the  timing  of  OPNAV  N782B’s  communication  that  the  requirements  for 
active-duty  Naval  aviators  was  going  to  be  reduced.  The  Naval  aviation  training  pipeline 
receives  the  bulk  of  its’  commissioned  officers  selected  for  aviation  in  the  May  to  June 
time  frame.  This  is  due  to  the  fact  that  the  majority  of  officers  receive  their  commissions 
in  the  month  of  May  because  most  commissioned  officers  are  graduates  from  a  collegiate 
academic  program,  whether  it  is  the  Naval  Academy  or  a  civilian  higher  education 
institution.  Though  some  officers  are  commissioned  in  other  months  throughout  the  year 
that  amount  is  insignificant  when  compared  to  the  numbers  of  officers  entering  the  Naval 
aviation  training  pipeline  in  the  early  summer  months.  The  news  of  the  reduced 
requirements  for  active-duty  Naval  aviators  was  disseminated  after  May  aviator  officer 
selections.  If  the  OPNAV  decision-making  process  had  considered  the  timing  of  the 
supply  for  pilot  and  NFO  production,  then  this  surplus  situation  could  have  been  avoided 
or  made  negligible  from  the  standpoint  of  numbers  of  excess  bodies.  The  OPNAV 
process  as  it  relates  to  the  capacity  management  of  the  Naval  aviation  training  pipeline 
was  not  within  the  scope  of  this  study,  but  it  is  worth  examining.  Manpower  is  one  of  the 
Chief  of  Naval  Operations  (CNO)  (Clark,  2005)  “Top  Five  Priorities”  and  creating 
excesses  in  manpower  wastes  precious  funding  resources. 
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Another  problem  contributing  to  the  Naval  aviation  training  pipeline  involved  the 
Integrated  Production  Plan  (IPP)  development  process  as  it  relates  to  servicing  the  Air 
Force,  the  Marine  Corps,  the  Flight  Surgeon  program,  and  the  IMT  program.  The  Naval 
aviation  training  pipeline  is  a  “pull”  system;  whereas,  the  other  entities  are  operating 
based  on  a  “push”  system.  According  to  Bonney  (1999),  Venkatesh  stated 

In  a  push  system,  a  preceding  machine  produces  parts  without  waiting  for 
a  request  from  the  succeeding  machine.  On  the  other  hand,  in  a  pull 
system  a  preceding  machine  produces  parts  only  after  it  receives  a  request 
from  the  succeeding  machine  (p.  54). 

These  aspects  of  the  IPP  development  process  were  not  within  the  scope  of  this 
study,  but  their  research  would  be  of  significant  importance  to  improving  the 
capacity  management  of  the  Naval  aviation  training  pipeline. 

2.  Training  Squadron  Flight  Scheduling  Process 

A  crucial  component  of  making  the  Naval  aviation  training  pipeline  a  more 
efficient  system  on  the  training  squadron  level  is  the  flight  scheduling  process.  At 
Training  Air  Wing  (TRAWING)  6  on  the  extreme  end  of  the  spectrum  the  flight 
scheduling  process  consumes  3  hours  of  the  day  within  Flight  Training  Squadron  (VT)  10 
and  only  one  hour  within  VT  4.  The  Navy  has  fewer  training  aircraft  resources  than  the 
Air  Force  according  to  Air  Force  instructors  at  TRAWING  6.  This  is  understandable 
considering  that  air  warfare  is  not  the  only  combat  role  performed  by  the  Navy. 

The  flight  scheduling  tool  used  by  the  training  squadrons  at  TRAWING  6  are 
“Puck”  boards  (Figure  28).  “Puck”  boards  are  essentially  dry  eraser  boards  that  are  used 
to  track  student  completion  of  syllabus  events  throughout  a  phase  of  training.  This  is 
accomplished  by  replicating  the  training  phase  syllabus  onto  a  dry  eraser  board  through 
the  use  of  magnetic  placeholders  for  syllabus  events  and  student  names.  Then  as  a  student 
completes  each  syllabus  event  a  circular  magnetic  device,  also  called  a  “Puck”,  is  placed 
in  the  appropriate  area  on  the  dry  eraser  board.  Officers  assigned  the  duties  of  planning 
the  daily  flight  schedule  have  to  deal  with  limitations  in  the  number  available  aircraft,  the 
number  of  qualified  instructors  available  to  fly,  and  whether  the  actual  weather  makes  it 
permissible  to  conduct  training  flights. 
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Figure  28.  “Puck”  Board  Picture.  (From:  TRAWING  6,  2005) 


At  the  training  level  the  Navy  and  Air  Force  has  invested  over  three  years  in 
developing  an  automated  tool,  the  Training  Integration  Management  System  (TIMS),  to 
simplify  this  process.  The  TIMS  software  is  intended  to  be  a 

...centralized  training  system  that  will  provide  cradle -to-grave 
management  of  all  training  assets  and  student  accomplishments.  With 
TIMS,  a  scheduler  will  get  fully  customized  scheduling  templates, 
displays  and  formats  as  well  as  drag-and-drop  capabilities.  All  syllabus 
events  will  be  automatically  tracked  so  building  flight  schedules  will  be 
easier.  When  a  student  finishes  a  computer-based  training  lesson,  TIMS 
will  track  completion  of  that  event  so  a  scheduler  can  tell  from  his 
workstation  if  a  student  is  ready  for  the  next  event  in  the  syllabus.  After  a 
flight  or  simulator  event,  an  instructor  will  complete  a  student’s  grade 
sheet  in  TIMS  and  those  results  will  be  automatically  available  to  a 
squadron  scheduler  at  another  workstation.  If  a  student  is  scheduled  for  an 
event  before  he  or  she  is  actually  ready  to  proceed  to  that  event,  TIMS  will 
alert  the  scheduler  to  the  conflict.  All  of  the  training  sites  will  be 
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connected  through  TIMS  so  that  students’  records  and  data  can  be 
transferred  electronically  as  they  move  through  the  aviation  training 
pipeline.  It  will  replace  three  different  legacy  data  management  systems 
currently  in  use  including  the  Training  Management  System  used  at  Naval 
Air  Station  Corpus  Christi  and  Pensacola,  the  Training  Integration  System 
used  at  Naval  Air  Station  Kingsville  and  Naval  Air  Station  Meridian,  and 
the  Standard  Training  and  Support  System  used  at  Naval  Air  Station 
Whiting  Field  (Hatcher,  2003). 

According  to  sources  at  the  Chief  of  Naval  Air  Training  (CNATRA),  there  was  a  flaw  in 
a  key  Navy  requirement  that  this  commander  identified  at  the  final  test  evaluation  for 
TIMS,  prior  to  the  Air  Force  and  Navy’s  acceptance  of  it  over  three  years  ago.  This 
requirement  was  the  capability  for  the  application  to  compute  training  grades  according 
to  the  Navy’s  standard,  which  is  different  from  the  Air  Force’s  standard.  The  developers 
found  an  error  in  a  parameter  variable  that  was  listed  throughout  the  entire  application 
code.  TIMS  has  yet  to  be  fully  implemented  throughout  all  naval  aviation  training  sites, 
and  those  three  legacy  data  management  systems  are  still  in  use. 

The  slow  development  of  a  good  automated  tool  for  aiding  OPSOs  with  the  flight 
scheduling  process  places  those  officers  with  expertise  in  flight  scheduling  at  a  premium. 
Also,  the  lack  of  a  centralized  database  that  is  integrated  throughout  all  CNATRA 
training  squadrons  results  in  CNATRA  production  analysts  having  to  use  multiple 
sources  (Figure  27)  or  highly  intricate  self-devised  tools  in  order  accurately  account  for 
all  students  within  the  Naval  aviation  training  pipeline.  This  fact  was  revealed  through 
the  survey  (Appendix  G)  conducted  with  individuals  in  the  Production  Department  at 
CNATRA.  The  above  subject  matter  was  not  within  the  scope  of  this  study,  but  it 
definitely  deserves  further  research,  and  it  is  an  important  element  to  properly  managing 
the  Naval  aviation  training  pipeline  capacity. 

3.  Contract  Support  Resources 

The  Naval  aviation  training  pipeline  is  not  only  supported  by  military  and 
government  personnel,  but  also  by  contracted  aircraft,  maintainers,  instructors,  analysts, 
and  consultants,  just  to  name  a  few.  The  interviews  conducted  at  CNATRA  revealed  the 
fact  that  it  can  take  as  long  as  1 8  months  to  secure  a  contract.  Comments  were  also  made 
to  indicate  that  it  is  sometimes  in  the  best  interest  of  a  contractor  that  is  providing  aircraft 
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and  maintainers  to  sell  the  Navy  on  a  higher  number  of  aircraft  in  order  to  ensure  the 
contractor  can  meet  the  aircraft  readiness  requirement  for  training.  This  could  mean  in 
certain  circumstances  at  specific  training  air  wings  the  Navy  has  more  of  a  particular  type 
of  aircraft  than  is  needed,  and  has  inadequate  numbers  of  other  types  of  aircraft.  The 
contract  cost  associated  with  the  T45  aircraft  alone  is  estimated  to  be  $154  million  for 
Fiscal  Year  (FY)  2006.  The  contract  cost  for  all  airframes  within  just  the  pilot  training 
program,  to  include  the  T45,  is  estimated  at  $222  million  for  FY  2006.  The  aircraft 
contract  cost  for  the  entire  NFO  training  program  is  estimated  at  $22  million  for  FY 
2006.  A  study  that  examines  the  current  aircraft  support  contract  for  the  Naval  aviation 
training  pipeline  could  ensure  it  is  structured  in  the  Navy’s  best  interest  for  obtaining  the 
type  and  quantity  of  aircraft  actually  needed  and  for  judiciously  appropriating  taxpayers’ 
dollars. 

4.  Capacity  Improvement  by  Organizational  Change 

It  is  the  authors’  opinion  that  the  Naval  aviation  training  pipeline  has  four 
decision-making  organizational  levels.  These  levels  include  OPNAV,  CNATRA,  the 
training  air  wings,  and  the  training  squadrons.  The  problems  identified  in  this  section 
pertain  to  CNATRA  and  training  air  wings. 

In  learning  about  the  IPP  development  process,  it  was  noted  that  the  training  air 
wings  are  allowed  to  determine  the  student  numbers  for  their  “Planned  Ins”  and  “Planned 
Outs”  for  each  phase  of  training  under  their  purview.  A  training  air  wing  should  be  more 
aware  of  their  own  training  phase  production  capacity  with  respect  to  the  appropriate 
number  of  students  that  can  be  loaded  in  a  training  squadron  at  one  time,  but  the 
“Planned  Outs”  for  meeting  fleet  requirements  may  best  reside  within  the  authority  of 
CNATRA.  Some  training  air  wings  may  manage  their  student  numbers  quite  well  with 
respect  to  meeting  fleet  requirements,  but  if  there  are  some  that  do  not,  then  the  aviation 
training  pipeline  will  be  burdened  with  unnecessary  excesses  in  numbers  of  students  or 
not  meet  fleet  goals  for  first  tour  aviators.  Neither  one  of  these  afore-mentioned  situations 
demonstrates  an  efficient  production  system,  thus  the  aspect  of  production  authority 
deserves  a  more  serious  review. 
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Now  in  regard  to  the  training  air  wing  organizational  structure,  one  of  the  Air 
Force  officers  interviewed  at  TRAWING  6  believed  that  the  compartmentalized 
organizational  structure  of  the  wing  hinders  the  overall  goal  of  producing  NFOs  in  a 
team-oriented  fashion.  For  example,  an  instructor  who  teaches  in  the  classroom  cannot  be 
an  in  flight  instructor.  Meaning,  the  academics  portion  of  NFO  training  is  a  separate 
department  from  the  actual  in  flight  training.  The  persons  in  leadership  for  these  two 
departments  are  the  same  rank.  This  type  of  leadership  structure  depending  on  the 
individuals  who  hold  these  positions  has  the  potential  to  be  an  incompatible  relationship. 
However,  there  are  weekly  meetings  in  which  the  individuals  responsible  for  flight 
training  and  academics  gather  with  other  parties  in  order  to  resolve  training 
organizational  conflicts. 

The  issues  that  were  raised  by  the  interviews  held  with  Air  Force  officers  and 
CNATRA  production  staff  deserves  a  closer  examination,  which  is  broader  than  the 
scope  of  this  study.  These  issues  should  be  taken  up  in  another  study  that  specifically 
analyzes  Naval  aviation  training  organizational  problems.  Sometimes,  organizational 
change  can  have  more  of  an  impact  than  any  new  automated  tool  created  to  aid  with 
mitigating  system  inefficiencies. 

C.  FINAL  STATEMENT 

This  study  has  revealed  that  the  Naval  aviation  training  pipeline  problem  with 
capacity  management  has  four  different  aspects  (Figure  29),  and  these  areas  are 
comprised  of  multiple  elements.  Solving  the  problem  for  only  one  of  these  areas  will  not 
solve  the  entire  aviation  training  pipeline  capacity  management  problem. 
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Figure  29.  Naval  Aviation  Training  Pipeline  Capacity  Management  Diagram. 

Capacity  management  for  the  Naval  aviation  training  pipeline  is  more  complicated  than 
one  study  could  ever  resolve.  This  study  presented  only  one  potential  solution  for  aiding 
with  the  capacity  management  of  the  Naval  aviation  training  pipeline.  Further  work  will 
definitely  be  required  for  more  progress  to  be  made  in  the  proper  methods  to  apply  for 
managing  the  Naval  aviation  training  pipeline  capacity. 
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APPENDIX  A.  DATA  ANALYSIS 


The  Figure  4  graph  was  composed  in  the  following  manner: 

1 .  Last  and  third  and  the  last  columns  of  data  from  the  Total.xls  spreadsheet  of  the 
“Fridge  Tool”  used  by  TRAWING  6.  Delta- WIP  is  the  extra  bodies  in  training. 
ACT/PROJ  IN  is  the  number  of  students  who  began  the  class.  The  Delta- WIP  is 
created  when  that  class  finishes.  For  example,  if  10  students  begin  and  9 
complete,  then  the  Delta- WIP  increases  by  1 . 
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Table  1.  VT  10  Primary  Training  Phase  Data.  (From:  TRAWING  6,  2004) 


2.  Created  a  third  column,  “6  ACT  IN”,  which  ran  a  running  sum  of  6  classes  or  6 
rows  worth  of  class  completers. 
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3.  Added  another  column,  “Delta- WIP”,  which  was  a  copy  of  the  original  Delta- 
WIP.  This  step  made  it  easier  to  graph  the  data  in  Excel. 

4.  The  graph  was  then  created  with  the  2  rightmost  columns. 

5.  The  x-axis  label  for  the  graph  was  the  completion  date  of  the  class. 
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Figure  30.  Six  Aggregate  Students  In  and  Delta  WIP  Totals. 
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Figure  31.  Six  Aggregate  Students  In  vs.  Delta  WIP. 
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APPENDIX  B.  QUESTIONNAIRE 


Questionnaire  in  support  of  NPS  Thesis  Project: 

PROTOTYPING  A  WEB-ENABLED  DECISION  SUPPORT  SYSTEM  TO 
IMPROVE  CAPACITY  MANAGEMENT  OF  AVIATION  TRAINING 


Questions  for: 


CNATRA 

TRAWING  6 

VT  10  OPSO 

VT  4  OPSO 

VT  86  OPSO 

You  are  our  customer.  The  success  of  this  project  largely  depends  on  the  information 
that  you  share  with  us.  Your  time  is  appreciated. 

The  purpose  of  the  following  questions  is  to  help  to  advance  our  understanding  of  the 
decision  process  from  generation  of  the  IPP  spreadsheets  to  the  person(s)  who  decide 
how  many  students  will  need  to  start  at  API  and  when. 


Please  call  me  (LCDR  Randy  Bostick)  @  850-313-4019  or  type  your  responses  into  this 
text  and  e-mail  it  to  rwbostick@nps.edu.  If  able,  please  complete  by  1600  Wednesday, 
26  JAN.  Thank  you  again  for  your  time. 


Project  Objective: 

-  To  provide  a  predictive  tool  which  allows  for  more  efficient  planning  and  use  of  training  resources 

_ (capacity)  in  relation  to  fluctuating  student  loading. _ 

Strategy: 

-  Analyze  process  from  API  to  FRS.  Use  NAPPI  work  as  reference. 

-  Determine  predictive  correlations  between  student  loading,  time-to-train,  and  capacity  limitations. 

-  Use  relationships  to  predict  periods  of  under/overcapacity  given  squadron  provided  data. 

-  Train  users  how  to  use  the  tool  in  order  to  help  them  plan  accordingly  for  future  periods  when  other  than  normal  rates  of  production 
_ will  be  required. _ 


Questions 

IPP 

1)  How  far  into  the  future  does  the  IPP  predict  demand? 

2)  How  often  is  the  IPP  produced? 

3)  Who  is  involved  in  deciding  IPP  Requirements/numbers? 

4)  Who  physically  creates  the  IPP  spreadsheet? 

5)  Who  would  be  considered  an  IPP  “Expert”  and  could  you  please  provide  their 
contact  information? 
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6)  How  is  the  IPP  Distributed  to  the  Wings? 

7)  How  often  do  students  begin  at  a  time  not  predicted  by  the  IPP?  For  example,  do 
all  services  /  countries  follow  the  IPP?  If  not,  how  often  do  they  deviate?  How 
much  time  in  advance  do  they  let  API  know  that  they  are  sending  students? 

8)  Are  there  any  easily  accessible  documents/presentations  that  you  can  think  of  that 
would  help?  If  so,  could  you  let  us  know  and  e-mail  the  document  /  link  /  or 
location? 


CNATRA 

9)  What  does  CNATRA  do  with  the  IPP?  Is  someone  in  charge  of  Wing 
production? 

10)  How  are  the  NIPDR  charts  currently  being  used?  By  who? 

11)  How  are  future  Wing  manning  /  resource  level  requirements  figured? 

12)  How  is  it  predicted  (what  process  is  used  to  determine)  that  resources  will  or  will 
not  meet  future  production  demands? 

13)  How  often  does  CNATRA  communicate  with  the  FRSs  concerning  production? 

14)  Are  there  any  easily  accessible  documents/presentations  that  you  can  think  of  that 
would  help?  If  so,  could  you  let  us  know  and  e-mail  the  document  /  link  /  or 
location? 


Wings 

15)  What  does  your  Wing  do  with  the  IPP?  Is  someone  in  charge  of  Wing 
production? 

16)  Who  in  each  wing  is  involved  in  the  process  of  converting  the  IPP  to  actual 
numbers  of  needed  students  to  start  each  class? 

17)  How  is  this  process  completed?  Spreadsheet?  Other? 

18)  How  are  the  start  numbers  sent  to  API?  If  by  meeting,  how  often?  By  e-mail? 
Does  API  ever  deny  requests?  If  so,  why? 

19)  How  are  the  NIPDR  charts  currently  being  used?  By  who? 

20)  How  is  Wing  manning  /  resource  levels  figured? 
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21)  How  is  it  currently  predicted  that  resources  will  or  will  not  meet  future  production 
demands? 

22)  What  is  the  current  process  to  determine  the  number  of  students  that  will  start  in 
each  primary  class? 

23)  Are  there  any  easily  accessible  documents/presentations  that  you  can  think  of  that 
would  help?  If  so,  could  you  let  us  know  and  e-mail  the  document  /  link  /  or 
location? 


Squadrons 

24)  What  are  the  main  factors  that  cause  students  (on  average)  not  to  finish  within 
their  allotted  Time-to-Train? 

25)  What  would  you  suggest  changing  to  ensure  that  the  required  number  of  students 
are  consistently  graduating  on  time? 

26)  How  is  it  currently  predicted  if  resources  will  or  will  not  meet  future  production 
demands?  Is  someone  in  charge  of  this?  If  so,  who? 

27)  When  writing  the  flight  schedule,  is  it  always  the  case  that  ALL  students  who 
need  flights  are  scheduled  for  a  flight?  (In  other  words,  can  every  student  who 
needs  a  flight  be  scheduled  for  one?)  If  not,  how  are  students  prioritized  to  fly  or 
not  fly? 

28)  How  are  the  NIPDR  charts  currently  being  used?  By  who? 

29)  How  are  future  Wing  manning  /  resource  levels  figured? 

30)  What  is  the  average  percentage  of  failed  tests  per  class? 

31)  What  is  the  percentage  of  roll  backs  caused  by  failed  tests? 

32)  What  are  the  other  factors  that  may  prevent  a  student  from  staying  with  his  or  her 
class  during  ground  school? 

33)  What  is  the  current  process  for  determining  how  many  flights  are  possible  for  the 
next  week?  Month?  Year? 

34)  Is  it  known  how  many  flights  will  be  required  for  a  class  in  a  given  time  period? 

35)  How  are  the  total  flights  required  in  a  given  time  period  determined?  For 
example,  how  is  it  determined  how  many  flights  will  be  required  next  month? 
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36)  Is  the  following  determined:  The  number  of  flights  that  will  be  required  to  be 
scheduled  given  that  some  percentage  will  be  cancelled  due  to  certain  variables? 
If  so,  how  is  it  determined? 

37)  What  is  the  current  process  to  determine  the  number  of  students  that  will  start  in 
each  primary  class? 

38)  Are  there  any  easily  accessible  documents/presentations  that  you  can  think  of  that 
would  help?  If  so,  could  you  let  us  know  and  e-mail  the  document  /  link  /  or 
location? 


39)  All, 

40)  Below  is  the  process  IPP  to  API  process  which  we  need  to  fully  understand. 

Please  add  any  who,  what,  where,  and  “interacts  with”  information  that  you  can  to 
ensure  that  we  have  an  accurate  view  of  the  process.  Thank  you. 
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APPENDIX  C.  PROTOTYPE  I  SCREENSHOTS  AND  CAPTIONS 
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Figure  32.  Prototype  I  DSS  Website  Screenshot  1. 


This  page  is  viewed  after  the  user  enters  their  username  and  password.  This  is  the 
home  or  main  page  of  the  “Aviation  Training  Resource  Usage  Forecaster” 
website. 
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Figure  33.  Prototype  I DSS  Website  Screenshot  2. 

This  page  is  viewed  by  clicking  on  the  “SYLLABUS”  hyperlink  located  on  the 
“Aviation  Training  Resource  Usage  Forecaster”  home  page.  The  “SYLLABUS” 
page  displays  a  listing  of  the  training  phases  associated  with  the  NFO  training 
pipeline,  the  allotted  time-to-train  for  each  one  of  the  those  training  phases,  and 
the  name  of  the  unit  responsible  for  hosting  the  listed  training  phases. 
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Figure  34.  Prototype  I  DSS  Website  Screenshot  3. 


This  page  is  viewed  by  clicking  on  any  of  the  “RELATED  CLASSES”  hyperlinks 
located  on  the  “SYLLABUS”  page.  The  “RELATED  CLASSES”  page  displays 
breakdown  of  the  student  numbers  associated  with  a  specific  NFO  training  class, 
training  phase,  and  training  unit.  This  page  also  gives  a  user  the  capability  to 
“ADD  NEW  CLASS”. 
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Figure  35. 


Prototype  I DSS  Website  Screenshot  4. 


This  page  is  viewed  by  clicking  on  any  of  the  “DAY  PLAN”  hyperlinks  located 
on  the  “SYLLABUS”  page.  The  “DAY  PLAN”  is  essentially  a  day  for  day 
breakdown  of  the  syllabus  for  a  specific  training  phase  at  a  specific  training  unit. 
The  listing  on  this  web  page  shows  the  specific  event  that  must  be  accomplished 
for  each  day  of  the  training  phase  syllabus.  Every  training  phase  event  is 
associated  with  a  specific  resource. 
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Figure  36.  Prototype  I DSS  Website  Screenshot  5. 

This  page  is  viewed  by  clicking  on  the  “RESOURCES”  hyperlink  located  on  the 
“Aviation  Training  Resource  Usage  Forecaster”  home  page.  The  “RESOURCES” 
page  provides  the  user  with  the  capability  for  viewing  resources  by  one  of  two 
listed  options. 
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Figure  37.  Prototype  I DSS  Website  Screenshot  6. 


This  page  is  viewed  by  clicking  on  the  “Show  Resource  Availability  for  all 
Dates”  hyperlink  located  on  the  “RESOURCES”  page.  The  “Show  Resource 
Availability  for  all  Dates”  page  displays  the  minimum  and  maximum  numbers 
associated  with  a  NFO  training  resource  for  a  specific  week.  The  user  must  derive 
this  data.  This  page  also  gives  a  user  the  capability  to  “ADD  NEW”  resources  to 
the  listing. 
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Figure  38.  Prototype  I  DSS  Website  Screenshot  7. 


This  page  is  viewed  by  clicking  on  the  “CLASS  VIEW”  hyperlink  located  on  the 
“Aviation  Training  Resource  Usage  Forecaster”  home  page.  The  “CLASS  VIEW” 
page  provides  the  user  with  the  capability  for  viewing  classes  by  one  of  two  listed 
options. 
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Figure  39.  Prototype  I  DSS  Website  Screenshot  8. 


This  page  is  viewed  by  clicking  on  either  one  of  the  two  “VIEW”  buttons  located 
on  the  “CLASS  VIEW”  page.  This  page  displays  a  breakdown  of  the  student 
numbers  associated  with  a  specific  NFO  training  class,  training  phase,  and 
training  unit. 
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Figure  40.  Prototype  I  DSS  Website  Screenshot  9. 


This  page  is  viewed  by  clicking  on  the  “PROCESS  FORECAST”  hyperlink 
located  on  the  “Aviation  Training  Resource  Usage  Forecaster”  home  page.  The 
“PROCESS  FORECAST”  page  provides  the  user  with  the  capability  to  select 
number  of  days  for  the  projected  forecast  that  will  be  processed  by  using  the  drop 
down  menu. 
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Figure  41.  Prototype  I  DSS  Website  Screenshot  10. 

This  page  is  viewed  by  clicking  on  the  “FORECASTED  GRAPHS”  hyperlink 
located  on  the  “Aviation  Training  Resource  Usage  Forecaster”  home  page.  The 
“FORECASTED  GRAPHS”  page  provides  the  user  with  the  capability  to  plot  a 
graphical  display  of  the  processed  data  by  selecting  one  of  the  four  options 
presented  within  the  content  of  the  page. 
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Figure  42.  Prototype  I  DSS  Website  Screenshot  11. 

This  graph  was  produced  from  the  first  option  on  the  “FORECASTED  GRAPHS” 
page.  The  graph  displays  data  for  a  resource,  like  T-6  aircraft,  selected  from  the 
drop  down  menu.  The  selected  resource  data  is  displayed  in  the  color  format  of 
orange,  red,  and  black.  Orange  data  points  indicate  the  numerical  amount 
available  for  use  of  the  selected  resource  on  a  specific  date.  Red  data  points 
indicate  the  numerical  amount  needed  for  use  of  the  selected  resource  on  a 
specific  date.  Black  data  points  indicate  the  numerical  amount  being  used  of  the 
selected  resource  on  a  specific  date. 
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Figure  43.  Prototype  I  DSS  Website  Screenshot  12. 

This  graph  was  produced  from  the  second  option  on  the  “FORECASTED 
GRAPHS”  page.  The  graph  displays  resource  data  for  a  specific  training  squadron 
during  a  specific  training  phase,  like  VT  10  Primary  T-6  aircraft,  selected  from 
the  two  drop  down  menus.  The  selected  resource  data  is  displayed  in  the  color 
format  of  orange,  red,  and  black.  Orange  data  points  indicate  the  numerical 
amount  available  for  use  of  the  selected  resource  on  a  specific  date.  Red  data 
points  indicate  the  numerical  amount  needed  for  use  of  the  selected  resource  on  a 
specific  date.  Black  data  points  indicate  the  numerical  amount  being  used  of  the 
selected  resource  on  a  specific  date. 
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Figure  44.  Prototype  I  DSS  Website  Screenshot  13. 


This  graph  was  produced  from  the  third  option  on  the  “FORECASTED 
GRAPHS”  page.  The  graph  displays  T-6  resource  data  for  a  specific  training 
squadron  during  a  specific  training  phase,  like  VT  4  Primary,  selected  from  the 
drop  down  menu.  The  selected  resource  data  is  displayed  in  the  color  format  of 
black  only.  The  data  points  indicate  the  numerical  amount  of  T-6  resources 
needed  for  use  by  a  specific  class  number. 
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Figure  45.  Prototype  I  DSS  Website  Screenshot  14. 

This  graph  was  produced  from  the  forth  option  on  the  “FORECASTED 
GRAPHS”  page.  The  graph  displays  classes’  data  for  a  specific  training  squadron 
during  a  specific  training  phase,  like  VT  4  Primary,  selected  from  the  drop  down 
menu.  The  selected  classes’  data  is  displayed  in  the  color  format  of  orange  and 
black.  Orange  data  points  indicate  the  number  of  students  in  a  specific  class  after 
a  training  phase.  Black  data  points  indicate  the  number  of  students  in  a  specific 
class  before  a  training  phase.  The  numbers  generated  to  produce  the  displayed 
data  points  are  based  on  the  minimum  and  maximum  numbers  associated  with  a 
NFO  training  resource  for  a  specific  week.  Those  minimum  and  maximum 
numbers  are  used  to  compute  the  minimum  and  maximum  events  that  can  be 
accomplished  for  a  training  phase. 
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APPENDIX  D.  PROTOTYPE  I  DATABASE  SCHEMA 


Microsoft  Access  was  the  software  chosen  to  implement  the  database  for  the 
prototype  DSS.  The  primary  purpose  for  establishing  a  database  behind  the  website  was 
the  necessity  for  a  repository  to  store  required  data  that  will  be  used  in  the  application 
processing  in  order  to  display  output  to  the  user,  which  they  can  use  to  make  decisions. 
Figure  40  is  an  actual  screen  shot  of  the  prototype  Microsoft  Access  database  schema. 


Figure  46.  Prototype  1  Schema. 
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ClassAsIs 


o  Identified  by  class  number  and  syllabus  (can  use  for  both  actual  and 
predicted) 

o  Contains  information  on  the  number  of  students,  the  type  of  students  (i.e., 
branch  of  military  service  or  international  designation),  and  the  date  they 
start  their  next  phase  of  training. 

o  This  object  contains  the  data  entered  by  the  user  prior  to  processing. 
Before  processing,  the  data  is  copied  to  ClassToBe  and  all  data  processing 
and  resulting  data  will  be  stored  in  ClassToBe  while  ClassAsIs  does  not 
change  during  processing. 


DayPlanResourceFor  Inputl 

o  Pertains  to  all  classes  within  a  phase, 
o  A  DayPlan  corresponds  to  each  day  of  the  syllabus, 
o  Each  day  within  a  syllabus  corresponds  to  an  event, 
o  An  Event  uses  a  resource  (i.e.,  aircraft,  simulator,  or  classroom). 


Syllabus 

o  TotalNumberDays  in  syllabus  are  dates  determined  by  the  class  end  date  - 
class  start  date. 

o  Syllabus  is  owned  by  a  unit. 

o  Each  phase  should  have  one  and  only  one  syllabus.  Each  class  should  be 
in  one  and  only  one  phase  at  a  time,  (phase  and  syllabus  are  synonymous 
in  the  schema) 


94 


ClassToBe 


o  Identified  by  class  number  (can  use  for  both  actual  and  predicted) 

o  Contains  information  on  the  number  of  students,  the  type  of  students,  and 
the  date  they  start  their  next  phase  of  training. 

o  This  type  of  class  is  considered  to  be  in  an  “Exit”  training  phase. 


DayPlan 

o  DayPlan  is  for  a  specific  day  of  a  specific  syllabus  for  a  specific  phase. 

o  Includes  auto  ID,  SyllabusName,  and  DayNumber 

o  DayType  refers  to  Classroom,  Simulator,  Flight,  or  Classroom/Flight. 

o  A  resource’s  usage  refers  to  the  number  of  units  that  are  available  for  that 
resource  in  a  given  week. 

o  Each  resource  has  the  following: 

o  Unique  name  or  model  number;  and 

o  Type,  (classroom,  simulator,  or  aircraft) 

o  Before  processing,  the  data  is  copied  from  ClassAsIs  to  ClassToBe  and  all 
data  processing  and  resulting  data  will  be  stored  in  ClassToBe,  while 
ClassAsIs  does  not  change  during  processing. 
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ResourceAvailability 

o  Many  resources  can  be  available  during  a  given  week. 

o  Records  the  minimum  and  maximum  X  completions  achievable  based  on 
the  available  resources. 

o  Each  resource  has  the  following: 

o  Unique  name  or  model  number. 

o  Type  (classroom,  simulator,  or  aircraft) 

SystemUser 

o  Independent  from  the  other  tables,  specifically  for  web  access, 
o  Username  is  a  unique  identifier. 

o  Password,  Rank,  Name,  Email,  and  Unit  are  required  entries, 
o  Phone  Number  is  optional, 
o  ReasonForAccess  is  required. 

o  AccessLevel  is  required,  but  entered  by  a  database  administrator,  (default 
permission  is  Read  only) 

Unit 

o  Expected  to  be  a  simple  lookup  table. 
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APPENDIX  E.  PROTOTYPE  I  NON-HTML  CODE 


ACODE.ASP . 98 

PUBLICDECLARATIONS.INC . 99 

ARRAYREFERENCES.INC . 101 

GENERALSUBROUTINES.INC . 105 

CON  VERTFROMD  AT  ABASE  .IN  C . Ill 

CONVERTTODAYS.INC . 113 

LOADFROMDATABASE.INC . 116 

PROCESSSTUDENTS.INC . 117 

SAVETODATABASE.INC . 123 
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A.  ACODE.ASP 

Description:  This  page  is  called  from  the  website  and  is  passed  a  forecast  length  number. 
It  calls  all  vbscript  code  to  process  the  forecast. 

<%@  LANGUAGE- 'VBSCRIPT"  %> 

<%  Option  Explicit  %> 

<meta http-equiv-'refresh"  content- T;  URL=aGraphS  elect,  asp  "> 

<%  Server. ScriptTimeout  =  2400  '<meta http-equiv-'refresh"  content-' 1;  URL=aGraphS elect. asp ">%> 
<html> 

<body> 

Standby! ! ! 

<P> 

<!— #include  file="Connections/Conn_is4220Primary.asp"  — > 

<!— #include  file="code/PublicDeclarations.inc"— > 

<!— #include  file="code/ArrayReferences.inc"— > 

<!— #include  file="code/GeneralSubroutines.inc"— > 

<!—  #include  file="code/LoadFromDatabase.inc"— > 

<!— #include  file="code/ConvertToDays.inc"— > 

<!— #include  file="code/ConvertFromDatabase.inc"— > 

<!-#include  file- 'code/ProcessStudents.inc"--> 

<!-#include  file="code/SaveToDatabase.inc"--> 

<% 

Call  LoadFromDatabase() 

Call  ConvertFromDatabase() 

'Call  Display  Array  InTable  (StudentArray) 

'Call  Display  Array  InTable  (Resources  AvailabilityDaily  Array) 

Call  ProcessStudents() 

'Call  Display  Array  InTable  (Resources  AvailabilityDaily  Array) 

'Call  SaveArrayAsTable(StudentArray,  "TrackStudents") 

'Call  Display  Array  InTable  (StudentArray) 

Redim  Preserve  TrackResourcesNeededTable(3,  Ubound(TrackResourcesNeededTable,2)-l) 

Redim  Preserve  TrackResourcesUsedTable(3,  Ubound(TrackResourcesUsedTable,2)-l) 

Call  SaveArrayAsTable(TrackResourcesNeededTable,  "TrackResourcesNeeded") 

Call  SaveArrayAsTable(TrackResourcesUsedTable,  "TrackResourcesUsed") 

Call  SaveStudentArrayAsTable(StudentArray,  "TrackStudentsFinish") 

%> 

*****  Processing  Completed  ***** 

</body> 

</html> 
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B.  PUBLICDECL  ARATIONS.IN  C 

Description:  Initialized  variable  used  throughout  code. 

<% 

response. write  "<p></p><p></p><strong>PublicDeclarations  Started  ..  </strong></p><p></p>" 

The  following  variables  are  Public  and  can  be  accessed  by  all  subroutines. 

’  =======  Variables  from  database  ========== 

’  Syllabus  array  will  be  loaded  with  the  table  of  the  same  name  from  the  Database 
Public  SyllabusArray 

'  DayplanResources  array  will  be  loaded  with  the  table  of  the  same  name  from  the  Database 
Public  DayplanResourcesArray 

’  DayplanResources  array  will  be  loaded  with  the  table  of  the  same  name  from  the  Database 
Public  DayplanArray 

’  ClassAsIs  array  will  be  loaded  with  the  table  of  the  same  name  from  the  Database 
Public  ClassAsIsArray 

'  ResourceAvailability  array  will  be  loaded  with  the  table  of  the  same  name  from  the  Database 
Public  ResourceAvailability  Array 

'  ClassDatesArray  will  be  loaded  with  the  table  of  the  same  name  from  the  Database 
Public  ClassDatesArray 

’  NormalOffArray  array  will  be  loaded  with  the  table  of  the  same  name  from  the  Database 
Public  NormalOffArray 

’  =======  used  for  processing  =========== 

’  Student  array  -  each  student  will  be  processed  individually.  ClassAsIs  will  be  converted  into  this  array. 
Public  StudentArray 

’  ResourcesAvailabilityDaily  Array  -  ResourceAvailability  Array  (Weekly)  will  be  converted  to  a  Daily 
Array 

Public  ResourcesAvailabilityDaily  Array 

’  Resources  Availability  Weekly  Array  -  Resource  AvailabiltyDaily  Array  will  be  converted  to  a  Weekly 
Array. 

Public  Resouces  Availability  Weekly  Array 

’  ResourceUsage  Array  -  Used  to  track  resource  usage 
Public  ResourceUsage  Array 

'  ===========  used  to  store  information  back  into  the  database  =========== 


Public  ClassToBe Array 
DB 

Public  ResourcesByClassArray 
Public  ResourcesByPhaseArray 
Public  ResourcesByWeekArray 


'Empty  and  will  be  filled  during  processing  and  then  saved  to 

'will  be  saved  later  to  the  table  of  the  same  name  from  the  Database 
'will  be  saved  later  to  the  table  of  the  same  name  from  the  Database 
'will  be  saved  later  to  the  table  of  the  same  name  from  the  Database 


99 


’  ==========================  Declarations  =============================== 

'  Inlude  file  which  has  row  references  for  each  table  column  name 

Dim  StartDate 
Dim  EndDate 

StartDate  =  38432 
’EndDate  =  38439 

EndDate  =  StartDate  +  Session(’’RunLength’’) 

response  wntc^’^br^^ Start*  ”  &  StartDate  &  ”  EndDate*  ” 
&  EndDate) 

’if  IsDate(StartDate)  then 
’  response.write(CDate(StartDate)) 

’  response. write(Year(StartDate)) 

’end  if 

response. write  ”</p><strong>PublicDeclarations  Completed  ..  </strong></p>” 


C.  ARRAYREFERENCES.INC 

Description:  More  public  variable  definitions.  Names  all  pertinent  array  variables  to 
match  up  with  database  names  to  make  code  more  readable. 

<% 

’The  following  variables  are  Public  and  can  be  accessed  by  all  subroutines. 

’  =======  Variables  from  database  ========== 

’Table  is  DayplanResourcesForlnputl 

Public  D  ID 

Public  DSyllabusName 

Public  DClassNumber 

Public  D  Date 

Public  D_SyllabusEvent 

Public  D  Description 

Public  DClassroom 

Public  D  T34 

Public  D_T6 

Public  D  TI 

Public  D  T39 

Public  D_T2 

Public  D  SIMl 

Public  D  SIM2 

’Table  is  Resource  Availability 
Public  R  ID 
Public  RDate 

Public  RMaxAvailableUsageClassroom 
Public  R_MaxAvailableUsageT34 
Public  R_MaxAvailableUsageT6 
Public  R  MaxAvailableUsageTl 
Public  R_MaxAvailableUsageT39 
Public  R_MaxAvailableUsageT2 
Public  RMaxAvailableUsageSiml 
Public  R_MaxAvailableUsageSim2 

’Table  is  Syllabus 
Public  S  SyllabusName 
Public  S  TotalNumberDays 
Public  S  Unit 
Public  S  NextPhase 
Public  S  NextAltematePhase 

’Table  is  Class Asls 

Public  C  ClassAsIS  ID 

Public  C  SyllabusName 

Public  C  ClassNumber 

Public  C  PhaseType 

Public  C  PhaseStartDate 

Public  C  NumberNavy 

Public  C  NumberNavyT o AlternatePhase 

Public  C  NumberMarine 
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Public  CNumberAF 

Public  CNumberIMT 

Public  C  TotalNumberOfStudents 


'Now  set  them  to  a  number 

'Table  is  DayplanResourcesForlnputl 

DID  =  0 

D_SyllabusName=  1 
D_ClassNumber=2 
DDate  =  3 
D_SyllabusEvent  =  4 
DDescription  =  5 
DClassroom  =  6 
DT34  =  7 
D_T6  =  8 
DTI  =  9 
DT39 = 10 
D_T2  =  1 1 
DSIMl  =  12 
D  SIM2  =  13 


'Resources  names  and  NumberOf 
Public  D_ResourceName(7)  '8  resources 
Public  DNumberOfResourceTypes 

Public  DFirstResourcelndex  'From  the  DayplanResources Array,  the  1st  one  that  is  a  Resource 

DNumberOfResourceTypes  =  8 
DFirstResourcelndex  =  6 

DResourceName(O)  =  "Classroom" 

DResourceName(l)  =  "T-34" 

D_ResourceName(2)  =  "T-6" 

D_ResourceName(3)  =  "T-l" 

D_ResourceName(4)  =  "T-39" 

D_ResourceName(5)  =  "T-2" 

D_ResourceName(6)  =  "SIM1" 

D_ResourceName(7)  =  "SIM2" 


'Table  is  Resource  Availability 
Public  R  FirstResourcelndex 
RFirstResourcelndex  =  2 

Public  R  ResourceRefToResource Availability Array(7)  '8  resources 

RResourceRefToResource  Availability  Array  (0)  =  2 
RResourceRefToResourceAvailabilityArray(l)  =  6 
RResourceRefToResource  Availability  Array  (2)  =  8 
RResourceRefToResource  Availability  Array  (3)  =11 
RResourceRefToResource  Availability  Array  (4)  =13 
RResourceRefToResource  Availability  Array  (5)  =15 
RResourceRefToResource  Availability  Array  (6)  =17 
RResourceRefToResource  Availability  Array(7)  =  20 

RID  =  0 
RDate  =  1 

RMaxAvailableUsageClassroom  =  2 
R_MaxAvailableUsageT34  =  6 
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R_MaxAvailableUsageT6  =  8 
R_MaxAvailableUsageTl  =  11 
R_MaxAvailableUsageT39  =13 
R_MaxAvailableUsageT2  =  15 
R_MaxAvailableUsageSiml  =  17 
R_MaxAvailableUsageSim2  =  20 

Table  is  Syllabus 
SSyllabusName  =  0 
STotalNumberDays  =  1 
S_Unit  =  2 
SNextPhase  =  3 
SNextAltematePhase  =  4 

Table  is  Class Asls 
CClassAsISID  =  0 
CSyllabusName  =  1 
C_ClassNumber  =  2 
CPhaseType  =  3 
CPhaseStartDate  =  4 
CNumberNavy  =  5 
CNumberNavyToAlternatePhase  =  6 
CNumberMarine  =  7 
CNumberAF  =  8 
CNumberIMT  =  9 
C  TotalNumberOfStudents  =  10 


Dim  TypeToC(lO) 

’Used  to  convert  Class  Asls  Column  into  a  number 

representing  Student  Type 

Const  CTypes  =  4 

TypeToC(0)=5  'Navy 
TypeToC(l)=7  'Marine 
TypeToC(2)=8  'AF 
TypeToC(3)=9  ’IMT 

’Student Array  References 

Public  ST  SyllabusRef 

Public  ST  StartClassNumber 

Public  ST  CurrentClassNumber 

Public  ST  PhaseStart 

Public  ST  Type 

Public  ST  InPhase 

Public  ST  TotalResourcesRequired 

Public  ST  PhaseEnd 

Public  ST  FirstResourcelndex 

ST  FirstResourcelndex  =  8  'First  column  that  is  a  resource  in  the  StudentArray 

STSyllabusRef  =  0 
STStartClassNumber  =  1 
ST  CurrentClassNumber  =  2 
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STPhaseStart  =  3  'Class  date  students  class  started  the  phase. 

ST  Type  =  4  'Navy,  Marine,  AF,  IMT 

STInPhase  =  5  'T/F  Is  the  student  currently  in  phase?  or  not. 

STTotalResourcesRequired  =  6 

ST  PhaseEnd  =  7'Class  date  students  are  planned  to  end  the  phase. 

'8  onward  is  Specific  required  resources. 

'Here,  we  have  eight,  as  defined  by  D  NumberOfResourceTypes  defined  in  TableColumn..inc 
'So,  8  through  15  will  be  filled  with  Classroom  to  SIM2  reference  values. 

'Refs  for  ResourceTable Storage 
Public  TrackResourcesNeededTable 
Public  TrackResourcesUsedTable 
ReDim  TrackResourcesNeededTable(3,0) 

ReDim  TrackResourcesUsedTable(3,0) 

response. write  "</p><strong>ArrayReferences  Completed  ..  </strong></p>" 

%> 
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D. 


GENERALSUBROUTINES.INC 


Description:  Routines  that  were  used  by  different  .inc  files  were  placed  here. 


<script  language-’JScript”  runat=”server”> 
function  UDim(vbarr)  {  return  vbarr.dimensions();  } 

</script> 

<% 

Private  Sub  Display  Array  InTable  (NameOf Array) 

Dim  Counter 
Dim  Filler 
’Display  Results 

Dim  InRowCounter,  InColumnCounter 
Response.Write  (”<br>”  &  ”FYI:””.””  =  0”) 

Response. Write  (”<table  width- ’”100%””  border- ”T””  cellspacing=””0’’’’  cellpadding- ”'0””>”) 
Response.Write  (”<tr  bgcolor=””#99CCFF””>”) 

Response.Write  (”<th  width=””200””  scope=””col””>”  &  ”Ref#”  &  ”</th>”) 

For  InColumnCounter  =  0  To  Ubound(NameOfArray,l) 

Response.Write  (”<th  width=’”’200””  scope=””col””>”  &  InColumnCounter  &  ”</th>”) 

Next 

Response.Write(”</tr>”) 

For  InRowCounter  =  0  To  Ubound(NameOfArray,2) 

Response.Write  (”<tr>”) 

Response.Write  (”<th  width- ”’200””  bgcolor=””#99CCFF””  scope=””col””>"  & 
InRowCounter  &  ”</th>”) 

For  InColumnCounter  =  0  To  Ubound(NameOfArray,l) 

Filler  =  NameOf  Array  (InColumnCounter,  InRowCounter) 

If  IsNull(Filler)  then 

Filler  =  "&nbsp" 

Elself  IsNumeric(Filler)  then 
If  Filler=  0  then 
Filler  = 

End  If 

End  If 

Response.Write  (”<th  width-’ ”200””  scope- ”’col”">”  &  Filler  &  ”</th>”) 

Next 

Response.Write(”</tr>”) 

Next 

Response.Write  (”</table>”) 
response.write  ”</p></p>” 

End  Sub 

Private  Sub  Display  Array  InTableOneColumn(NameOf Array) 

Dim  Counter 
Dim  Filler 
’Display  Results 

Dim  InRowCounter,  InColumnCounter 
’Response.write  (UDim(NameOfArray)) 

Response.write  (”<table  width- ’”100%””  border- cellspacing- ’”0"”  cellpadding- ”'0””>”) 


Response.write  (”<tr  bgcolor=””#99CCFF””>”) 
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Response.Write  ("<th  width- ”’200’”’  scope- ”’cor">"  &  "Ref#"  &  "</th>") 

InColumnCounter  =  0 

Response.Write  ("<th  width=""200""  scope=""col"">"  &  InColumnCounter  &  "</th>") 
Response.Write("</tr>") 

For  InRowCounter  =  0  To  Ubound(NameOfArray,l) 

Response.Write  ("<tr>") 

Response.Write  ("<th  width=’”’200'”’  bgcolor=’”’#99CCFF’”’  scope=’”’col’”’>"  & 
InRowCounter  &  "</th>") 

InColumnCounter  =  0 

Filler  =  NameOfArray(lnRowCounter) 

If  IsNull(Filler)  then 

Filler  =  "&nbsp" 

’  A  failed  attempt  to  display  dates  instead  of  numbers 
’Elseif  IsNumeric(Filler)  then 
’  If  Filler  >  30000  then 

’  Filler  =  DateValue(Clng(Filler)) 

’  End  If 

End  If 

Response.Write  ("<th  width=’”’200’”’  scope=’”’col’”’>"  &  Filler  &  "</th>") 
Response.Write("</tr>") 

Next 

Response.Write  ("</table>") 
response.write  "</p></p>" 

End  Sub 

Private  Sub  Display ArrayInTableRows(NameOfArray,  StartRow,  EndRow) 

Dim  Counter 
Dim  Filler 
’Display  Results 

Dim  InRowCounter,  InColumnCounter 
’Response.write  (UDim(NameOfArray)) 

Response.write  ("<table  width=’”’100%’”’  border=’”’ 1 ’”’  cellspacing=’”’0’”’  cellpadding=’”’0’”’>”) 
Response.write  ("<tr  bgcolor=’”’#99CCFF’”’>") 

Response.write  ("<th  width- ”’200’”’  scope=’”’cor”’>"  &  "Ref#"  &  "</th>") 

For  InColumnCounter  =  0  To  Ubound(NameOfArray,l) 

Response.write  ("<th  width- ”’200’”’  scope=’”’col’”’>’’  &  InColumnCounter  &  "</th>") 

Next 

Response.Write("</tr>") 

’Make  sure  Start  to  EndRow  are  in  range 
If  StartRow  <  0  then 
StartRow  =  0 

End  If 

If  EndRow  >  Ubound(NameOfArray,2)  then 
EndRow  =  Ubound(NameOfArray,2) 

End  If 

For  InRowCounter  =  StartRow  To  EndRow 
Response.write  ("<tr>") 

Response.write  ("<th  width=’”’200'”’  bgcolor=’”’#99CCFF’”’  scope=’”’col’”’>"  & 
InRowCounter  &  "</th>") 

For  InColumnCounter  =  0  To  Ubound(NameOfArray,l) 

Filler  =  NameOf Array  (InColumnCounter,  InRowCounter) 
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If  IsNull(Filler)  then 

Filler  =  "&nbsp" 

'  A  failed  attempt  to  display  dates  instead  of  numbers 
'Elseif  IsNumeric(Filler)  then 
’  If  Filler  >  30000  then 

'  F  iller  =  Date  V  alue(Clng(F  iller)) 

'  End  If 

End  If 

Response.Write  ("<th  width=""200""  scope=""col"">"  &  Filler  &  "</th>") 

Next 

Response.Write("</tr>") 

Next 

Response.Write  ("</table>") 
response.write  "</p></p>" 

End  Sub 

Private  Sub  LoadArray  (NameOfArray,  NameOfTable) 

'Fills  an  array  from  the  given  NameOfTable 
Dim  Table 

Dim  InRowCounter,  InColumnCounter 

Set  Table  =  Server. CreateObject("ADODB. Recordset") 

Table. Open  "SELECT  *  FROM  "  &  NameOfTable,  MM_Conn_is4220Primary_STRING 
NameOfArray  =  Table. GetRows()  'Sucks  the  entire  table  into  an  Array 

Response.Write("Table:  "  &  """  &  NameOfTable  &  """  &  "  Successfully  Loaded  into  an  array"  & 

"<br>") 

Table. Close 

End  Sub 

Private  Sub  LoadArrayByDate  (NameOfArray,  NameOfTable,  NameOfDateField) 

'Send  it  the  Field  name  where  the  date  is  stored,  and  it  will  load  only  the  dates  between  StartDate  and 
EndDate 

Dim  Table 

Dim  InRowCounter,  InColumnCounter 

Set  Table  =  Server. CreateObject("ADODB. Recordset") 

Table. Open  "SELECT  *  FROM  "  &  NameOfTable  &  "  WHERE  "  &  NameOfTable  &  "."  & 
NameOfDateField  &  ">="  &  StartDate  &  "  And  "  &  NameOfTable  &  "."  &  NameOfDateField  &  "<="  & 
EndDate  &  "  ORDER  BY  "  &  NameOfTable  &  "."  &  NameOfDateField, 
MM_Conn_is4220Primary_STRING 

'Modified  to  account  for  times  where  no  record  existed  between  Start  and  EndDates:  Errors  occur 
otherwise 

'Table. Open  "SELECT  *  FROM  "  &  NameOfTable  &  "  ORDER  BY  "  &  NameOfTable  &  "."  & 
NameOfDateField,  MM_Conn_is4220Primary_STRING 
NameOfArray  =  Table.  GetRows() 

Response.Write("Table:  "  &  NameOfTable  &  "  Successfully  Loaded  into  an  array"  &  "<br>") 
Table. Close 

End  Sub 


Function  RetumClassEndDate(SyllabusRef,  ClassNumber) 

'Given  the  SyllabusRecord  row  number  in  SyllabusArray,  it  returns  the  last  date  for  the  Class  in  that 
Syllabus 

'Find  Syllabus  and  Class  then  get  the  Date 
Dim  Found 
Dim  Count 
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Dim  TempDate 
Dim  SyllabusName 
Found  =  False 
Count  =  0 

SyllabusName  =  SyllabusArray(0,  SyllabusRef) 

’Response.Write("<br>"  &  "Syllabus:  "  &  SyllabusName) 

TempDate  =  Cdate("l  0/1 0/2020") 

Do 

If  (ClassDatesArray(0,  Count)  =  SyllabusName)  and  (ClassDatesArray(l, 
Count)=ClassNumber)  then 

'If  (ClassDatesArray(l,  Count)=  ClassNumber)  then 
TempDate  =  ClassDatesArray(3,  Count) 

Found  =  True 

End  If 

Count  =  Count  +  1 

Loop  While  (Found=False)  and  (count  <=  Ubound(ClassDates Array,  2)) 
'Response.Write("<br>  *************TEMP  DATE  "  &  TempDate) 
RetumClassEndDate  =  TempDate 
End  Function 

Function  RetumClassStartDate(SyllabusRef,  ClassNumber) 

'Find  Syllabus  and  Class  then  get  the  Date 

Dim  Found 

Dim  Count 

Dim  TempDate 

Dim  SyllabusName 

Found  =  False 

Count  =  0 

SyllabusName  =  Sy llabus Array (0,  SyllabusRef) 

’Response.Write("<br>"  &  "Syllabus:  "  &  SyllabusName) 

TempDate  =  Cdate("  10/1 0/2020") 

Do 

If  (ClassDatesArray(0,  Count)  =  SyllabusName)  and  (ClassDatesArray(l, 
Count)=ClassN umber)  then 

'If  (ClassDatesArray(l,  Count)=  ClassNumber)  then 
TempDate  =  ClassDatesArray(2,  Count) 

Found  =  True 

End  If 

Count  =  Count  +  1 

Loop  While  (Found=False)  and  (count  <=  Ubound(ClassDates Array,  2)) 
RetumClassStartDate  =  TempDate 
End  Function 

Function  IsInPhase(SyllabusRef,  ClassNumber,  Date  Value) 

'If  the  given  ClassNumber,  and  Date,  it  returns  if  the  class  is  still  in  the  Phase  on  that  Date 
Dim  Date 
Dim  Found 
Found  =  False 

Date  =  Clng(Date  Value) 

If  (Date  >=  (RetumClassStartDate(SyllabusRef,  ClassNumber)))  and  (Date  <= 
(RetumClassEndDate(SyllabusRef,  ClassNumber)))  then 
Found  =  True 

End  If 

IsInPhase  =  Found 
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End  Function 


Function  GetSyllabusNumber(SyllabusName) 

'Given  the  text  name  of  a  syllabus,  it  will  return  the  equivelant  row  number  in  the  SyllabusArray,  or  999  if 
not  found. 

Dim  X 
Dim  Temp 
Temp  =  999 

For  X=0  to  ubound(Syllabus Array,  2) 

’Response.Write("<br>"  &  X  &  "Syllabus:  "  &  SyllabusArray(0,  X)) 
’Response.Write("<br>"  &  X  &  cstr(SyllabusName)  &  "  :  "  &  cstr(SyllabusArray(0,  X))) 
If  cstr(SyllabusName)=cstr(SyllabusArray(0,  X))  then 
Tf  X=3  then 

'Response.  Write("Yeyaaaaa") 

Temp  =  X 

End  If 

Next 

GetSyllabusNumber  =  Temp 
End  Function 


Function  RetumRowValuesl(InArray,  Column  1,  Value  1) 

'Returns  the  row  given  (1)  An  Array  (2)  Column  Number  (3)  Value  seeking 
'Returns  99999  if  none  found 

'Best  used  for  columns  of  data  where  there  are  no  duplicate  values. 

Dim  Found 
Dim  Count 
Dim  TempRow 

TempRow  =  99999 
Found  =  False 
Count  =  0 
Do 

If  InArray(Columnl,  Count)  =  Value  1  then 
TempRow  =  Count 
Found  =  True 

End  If 

Count  =  Count  +  1 

Foop  While  (Found=False)  and  (count  <=  Ubound(InArray,  2)) 

ReturnRowValuesl  =  TempRow 
End  Function 

Function  RetumRowValues2(InArray,  Columnl,  Valuel,  Column2,  Value2) 

'Returns  the  row  given  where  Value l,Value2  are  found  for  the  given  corresponding  columns 
'Returns  99999  if  none  found 

'Best  used  for  columns  of  data  where  there  are  no  duplicate  values. 

Dim  Found 
Dim  Count 
Dim  TempRow 

TempRow  =  99999 
Found  =  False 
Count  =  0 
Do 
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If  (InArray(Columnl,  Count)  =  Value  1)  and  (CInt(InArray(Column2,  Count))  = 
CInt(Value2))  then  ’CInt  used  as  temp  fix  for  Rollback,  ConvertFromDatabase 
TempRow  =  Count 
Found  =  True 

End  If 

Count  =  Count  +  1 

Loop  While  (Found=False)  and  (count  <=  Ubound(InArray,  2)) 

ReturnRowValues2  =  TempRow 
End  Function 

Function  RetumRowValues3(InArray,  Columnl,  Valuel,  Column2,  Value2,  Column3,  Value3) 

’Returns  the  row  given  where  Value l,Value2  and  Value3  are  found  for  the  given  corresponding  columns 
’Returns  99999  if  none  found 

’Best  used  for  columns  of  data  where  there  are  no  duplicate  values. 

Dim  Found 
Dim  Count 
Dim  TempRow 
TempRow  =  99999 
Found  =  False 
Count  =  0 
Do 

If  (InArray(Columnl,  Count)  =  Valuel)  then 

If  (InArray(Column2,  Count)  =  Value2)  then 

If(InArray(Column3,  Count)  =  Value3)  then 
TempRow  =  Count 
Found  =  True 

End  If 

End  If 

End  If 

Count  =  Count  +  1 

Loop  While  (Found=False)  and  (count  <=  Ubound(InArray,  2)) 

ReturnRowValues3  =  TempRow 
End  Function 

%> 
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E. 


CONVERTFROMDATABASE.INC 


Description:  Converts  the  raw  arrays  loaded  from  database  into  usable  form. 

(1)  Converts  weekly  availability  into  daily. 

(2)  Converts  classes  into  individual  students. 


<% 

Private  Sub  ConvertFromDatabase() 

'Converts  weekly  resource  values  to  Daily 

Resources  AvailabilityDailyArray  =  ConvertToDay  s(Resource  Availability  Array  ,NormalOff Array) 
response.write  "</p></p><strong> Weekly  Availability  Table</strong>" 

Call  Display  ArraylnTable  (Resource  Availability  Array) 

Call  ClearRecords("TrackResourcesAvailableDaily") 

Call  SaveDaily ArrayAsTable(ResourcesAvailabilityDaily Array, "TrackResourcesAvailableDaily") 

response.write  "</p></p><strong>Daily  Availability  Table</strong>" 

Call  Display  ArraylnTable  (Resources  AvailabilityDailyArray) 

Call  ConvertClassesToStudents(ClassAsIsArray,  StudentArray) 

Call  SaveStudentArrayAsTable(StudentArray,  "TrackStudentsStart") 

'Call  Display  ArraylnTable  (StudentArray) 

End  Sub 

Private  Sub  ConvertClassesToStudents(ClassAsIsArray,  StudentArray) 

'  Subroutine  will  go  row  by  row  through  the  ClassAsIsArray  and  convert 
'  ALL  classes  in  that  table  into  the  corresponding  invididual  students. 

Const  TempHighStudentRange  =  100000 

Const  NumberOfAttributes  =15 

Redim  StudentArray(NumberOfAttributes,  1) 

Dim  CurrentClass 
Dim  StudentType 
Dim  Number StudentsInClass 

Dim  CurrentID  'increments  one  for  each  student  added 
Dim  StudentID  'Temporary  used  for  loop 
Dim  Column 

Dim  Temp  'Used  for  loop 

CurrentID  -  0 

For  CurrentClass  =  0  To  Ubound(ClassAsIsArray,2) 

For  StudentType  =  0  to  CTypes-1  'C_  refers  to  the  ClassAsIs  reference# 

Column  =  TypetoC(StudentType) 

NumberStudentsInClass  =  ClassAsIsArray(Column,  CurrentClass) 

For  Student  ID  =  CurrentID  to  (CurrentID  +  NumberStudentsInClass- 1) 

Redim  Preserve  StudentArray(NumberOfAttributes,  Student  ID) 
StudentArray(ST_SyllabusRef,  Student  ID)  = 
GetSyllabusNumber(ClassAsIsArray(C_SyllabusName,  CurrentClass)) 

StudentArray(ST_StartClassNumber,Student_ID)  = 
ClassAsIsArray(C_ClassNumber,  CurrentClass) 

StudentArray(ST_CurrentClassNumber,Student_ID)  = 
StudentArray(ST_StartClassNumber,  Student  ID) 

StudentArray(ST_PhaseStart,  Student  ID)  = 
ClassAsIsArray(C_PhaseStartDate,  CurrentClass) 


111 


StudentArray(ST_Type,  StudentID)  =  StudentType 
StudentArray(ST_InPhase,  Student  ID)  = 

IsInPhase(StudentArray(ST_SyllabusRef,  Student  ID),  ClassAsIsArray(C_ClassNumber,  CurrentClass), 
StartDate) 


StudentArray(ST_TotalResourcesRequired,  Student  ID)  =  0 
StudentArray(ST_PhaseEnd,  Student  ID)  = 

RetumClassEndDate(StudentArray(ST_SyllabusRef,  Student_ID),ClassAsIsArray(C_ClassNumber, 
CurrentClass)) 


StudentID)) 

DNumberOfResourceTypes 


’response.write("******  PhaseEnd  =  "  &  StudentArray(ST_PhaseEnd, 
For  Temp  =  ST_PhaseEnd+l  to  STPhaseEnd  + 


StudentArray(Temp,  Student  ID)  =  0 


Next 


Next 

CurrentID  =  CurrentID  +  NumberStudentsInClass 


Next 


Next 

’ReDim  Preserve  StudentArray(13,  CurrentID) 

End  Sub 


Sub  CreateStudent(SyllabusName,  ClassNumber,  StudentType) 

Const  NumberOfAttributes  =15 
Dim  Temp 

Dim  ClassDatesRow 
Dim  Student  ID 

’response.write("<br>"  &  SyllabusName  &  "  "  &  ClassNumber  &  "  "  &  StudentType) 
StudentID  =  Ubound(StudentArray,2)+l 

ClassDates  Row  =  RetumRowValues2(ClassDatesArray,  0,  SyllabusName,  1,  ClassNumber) 
’response.write("  -Row  :  "  &  ClassDates  Row) 

'ClassDatesRow  =  10 

Redim  Preserve  StudentArray(NumberOfAttributes,  Student  ID) 

'Student  ID  -  1 

'response. write("<br>  Redim  StudentArray(15, "  &  Student  ID  &  ")") 
StudentArray(ST_SyllabusRef,  Student  ID)  =  GetSyllabusNumber(SyllabusName) 
StudentArray(ST_StartClassNumber,Student_ID)  =  ClassNumber 
StudentArray(ST_CurrentClassNumber,Student_ID)  =  ClassNumber 
StudentArray(ST_Type,  Student  ID)  =  StudentType 
StudentArray(ST_InPhase,  Student  ID)  =  TRUE 
StudentArray(ST_TotalResourcesRequired,  Student  ID)  =  0 
If  ClassDates  Row  <>  99999  then 

StudentArray(ST_PhaseStart,  Student  ID)  =  ClassDatesArray(2,  ClassDates_Row) 
StudentArray(ST_PhaseEnd,  Student  ID)  =  ClassDatesArray(3,  ClassDates  Row) 

Else 

StudentArray(ST_PhaseStart,  Student  ID)  =  "1/1/2010" 
StudentArray(ST_PhaseEnd,  Student  ID)  =  "1/1/2010" 

End  If 

For  Temp  =  ST_PhaseEnd+l  to  ST  PhaseEnd  +  D  NumberOfResourceTypes 
StudentArray(Temp,  Student  ID)  =  0 

Next 

End  Sub 

%> 
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F. 


CONVERTTODAYS.INC 


Description:  Converts  weekly  availability  numbers  into  daily  numbers. 


<% 

Private  Function  ConvertToDays  (InArray, Date  Array) 
’InArray  Counters 

Dim  InRowCounter,  InColumnCounter 
InRowCounter  =  0 


’ResultantArray  Counters 

Dim  DailyRowCounter,  DailyColumnCounter 

’Declaring  Resultant  Array  to  be  multidimensional  of  variable  row  length 
Dim  ResultantArray() 

DailyColumnCounter  =  22 
DailyRowCounter  =  0 

ReDim  Preserve  ResultantArray(DailyColumnCounter,  DailyRowCounter) 

’Declaring  Day  Counters 

Dim  WeekDayCounter,  WeekDayCounter2 

’DateArrayCounters 

Dim  DateRowCounter,  DateColumnCounter,  DateRowCounter2 


’Used  to  calculate  Total  Days  of  Work  in  One  Week 
Dim  Days  On 


’Begin  Filling  Resultant  Table  by  beginning  with  Start  Date 
WeekDayCounter  =  StartDate 

For  WeekDayCounter  =  StartDate  To  EndDate  ’FLAW  Causes  problem  with 
LoadArrayByDate  if  no  values  in  range.  Use  Ubound 

’Determine  number  of  work  days  in  the  week  every  Monday  Date 
If  DateArray(l, DateRowCounter)  =  ’’MON”  Then 

DaysOn  =  0  ’must  reinitialize 


by  DaysOn,  we 


Determine  number  of  work  days  in  the  week  by  counting  days  of  work 
NOT  CURRENTLY  USED  since  Daily  Available  =  Weekly  Available  divided 

want  to  assume  the  users  enter  in  the  Weekly  Available  while  thinking  on 
a  full  week  basis.  As  a  result,  setting  DaysOn=5  will  prevent 
users  from  entering  standard  weekly  values  and  then  the  program 
giving  each  day  of  a  4  day  week  more  than  a  5  day  week 

For  WeekDayCounter2  =  WeekDayCounter  To  WeekDayCounter  +  6 

If  DateArray(4,DateRowCounter2)  =  False  Then 
DaysOn  =  DaysOn  +  1 

End  If 

’Prevents  DateRowCounter  from  going  beyond  total  size  of  array 
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If  Not  DateRowCounter2  =  Ubound(DateArray,2)  Then 
DateRowCounter2  =  DateRowCounter2  +  1 

End  If 


’Next 

DaysOn  =  5  ’Set  to  5  for  above  mentioned  explaination 

End  If 

’Fill  the  table  according  to  available  Data 

If  DateArray(4,DateRowCounter)  =  False  Then  ’Determine  Work  Day  Availability  by 
pulling  out  of  InArray 


If  DateArray(0,DateRowCounter)  >=  InArray(l,lnRowCounter)  AND 
DateArray(0,DateRowCounter)  <=  InArray(l,lnRowCounter)  +  6  Then 

For  InColumnCounter  =  0  To  0 

ResultantArray(lnColumnCounter,  DailyRowCounter)  = 

DailyRowCounter 

Next 

For  InColumnCounter  =  1  To  1 

ResultantArray(lnColumnCounter,  DailyRowCounter)  = 

W  eekDay  Counter 

Next 

For  InColumnCounter  =  2  To  Ubound(InArray,l) 

ResultantArray(lnColumnCounter,  DailyRowCounter)  = 
InArray(lnColumnCounter,  lnRowCounter)/DaysOn 

Next 

DailyRowCounter  =  DailyRowCounter  +  1 

ReDim  Preserve  ResultantArray(DailyColumnCounter, 

DailyRowCounter) 


Else  ’Work,  but  no  entries  for  Availability  =  0  Availability 

For  InColumnCounter  =  0  To  0 

ResultantArray(lnColumnCounter,  DailyRowCounter)  = 

DailyRowCounter 

Next 

For  InColumnCounter  =  1  To  1 

ResultantArray(lnColumnCounter,  DailyRowCounter)  = 

W  eekDay  Counter 

Next 

For  InColumnCounter  =  2  To  Ubound(InArray,l) 

ResultantArray(lnColumnCounter,  DailyRowCounter)  =  0 

Next 

DailyRowCounter  =  DailyRowCounter  +  1 

ReDim  Preserve  ResultantArray(DailyColumnCounter, 


DailyRowCounter) 
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End  If 


Else  ’No  Work,  therefore  0  Availability 

For  InColumnCounter  =  0  To  0 

ResultantArray(lnColumnCounter,  DailyRowCounter)  = 

DailyRowCounter 

Next 

For  InColumnCounter  =  1  To  1 

ResultantArray(lnColumnCounter,  DailyRowCounter)  = 

W  eekDay  Counter 

Next 

For  InColumnCounter  =  2  To  Ubound(InArray,l) 

ResultantArray(lnColumnCounter,  DailyRowCounter)  =  0 

Next 

DailyRowCounter  =  DailyRowCounter  +  1 

ReDim  Preserve  ResultantArray(DailyColumnCounter,  DailyRowCounter) 


End  If 

’Huge  hassle  to  get  thing  to  work  right... 

If  DateArray(0,DateRowCounter)  =  In  Array  (l,lnRowCounter)  +  6  Then 
If  Not  InRowCounter  =  Ubound(InArray,2)  Then 
InRowCounter  =  InRowCounter  +  1 

End  If 

End  If 

DateRowCounter  =  DateRowCounter  +  1 

Next 

Redim  Preserve  ResultantArray(Ubound(ResultantArray,l),  Ubound(ResultantArray,2)-l) 
ConvertToDays  =  ResultantArray 

End  Function 

%> 
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G.  LOADFROMDATABASE.INC 


Description:  Loads  database  tables  directly  into  arrays. 

<% 

Private  Sub  LoadFromDatabase() 

Dim  TableName 
Dim  FieldName 

response. write  ”</p><strong>LoadFromDatabase  Started  ..  </strong></p>" 

TableName  =  ’’Syllabus” 

Call  LoadArray  (SyllabusArray,  TableName) 

Call  Display  Array  InTable  (SyllabusArray) 

TableName  =  "DayplanResourcesForlnputl” 

Call  LoadArray  (DayplanResources Array,  TableName) 

’Call  Display ArraylnTable  (DayplanResources Array) 

TableName  =  "Dayplan” 

Call  LoadArray  (DayplanArray,  TableName) 

’Call  Display  ArraylnTable  (DayplanResources  Array) 

TableName  =  ’’ClassAsIs” 

Call  LoadArray  (ClassAsIs Array,  TableName) 

’Call  Display  ArraylnTable  (ClassAsIs  Array) 

Dim  ClassToBeArray() 

Redim  ClassToBeIsArray(Ubound(ClassAsIsArray,l),  0) 

TableName  =  ’’ClassStartEndDates” 

Call  LoadArray  (ClassDatesArray,  TableName) 

’Call  Display  ArraylnTable  (ClassDatesArray) 

TableName  =  ’’Resource  Availability” 

FieldName  =  ’’WeekDate” 

Call  LoadArrayByDate  (ResourceAvailability Array,  TableName,  FieldName) 
’Call  Display  Array  InTable  (Resource  Availability  Array) 

TableName  =  "NormalOff  ’ 

FieldName  =  "Date” 

Call  LoadArrayByDate(NormalOffArray,  TableName,  FieldName) 

’Call  Display  Array  InTable  (NormalOffArray) 

response. write  ”</p><strong>LoadFromDatabase  Completed  ..  </strong></p>” 

End  Sub 

%> 
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H. 


PROCESSSTUDENTS.INC 


Description:  Processes  events  day  by  day  for  each  student  and  decides  where  they  go 
next. 

<% 

'Student  processing  occurs  from  the  StartDate  to  EndDate  for  each  day,  including  daysoff 
'Generally,  it  operates  in  the  following  fashion 

'-  A  students  required  resources  are  retrieved,  and  added  to  the  students  required  resources 
'-  A  student  may  use  1  sim,  1  class,  or  2  flights  per  day. 

'  -Used  resources  are  subtracted  from  the  Resource  Availability  Array 

'-  If  no  resources  are  available,  none  are  used  and  required  resources  build  up  for  that  student. 

'-  A  student  rolls  back  a  class  when  their  ClassEndDate  passes  and  they  still  have  required  resources 
'  FUTURE:  also,  a  student  does  not  start  classroom  if  other  resources  are  still  required  -  so  they  are  rolled 
'  FUTURE:  also,  a  student  will  roll  one  10  classes  or  more  behind. 

'Once  a  student  (1)  has  reached  the  ClassEndDate,  they  are  passed  to  the  next  syllabus  as  determined  by 
SyllabusArray  and  ClassAsIs 

'Students  in  DUMMY  syllabii  (API,  Core,  etc..)  are  not  processed  because  their  syllabus  length  is  0 
'Students  will  be  drawn  into  Primary  from  API 

'Stats  will  be  saved  to  arrays  as  the  program  progresses.  These  arrays  will  later  be  saved  to  the  database. 

Public  RandomListArray() 

Sub  ProcessStudents() 

Dim  SCount 
Dim  SCounter 
Dim  CurrentDate 
Dim  UpperBound 

Call  ClearRecords("TrackResourcesNeeded") 

Call  ClearRecords("TrackResourcesUsed") 

For  CurrentDate  =  StartDate  to  EndDate  'Process  for  specified  range  of  dates. 

Call  RandomList()  'randomizes  the  array 

'Response.write("<br>###  RandomList Array:  "  &  "  "  &  RandomListArray(O)  &  "  "  & 
RandomListArray(  1 )) 

UpperBound  =  Ubound(StudentArray,  2) 

For  SCounter  =  0  to  UpperBound  'Process  ALL  students  from  StudentsAsIs 

SCount  =  RandomListArray(SCounter) 

'Scount  =  SCounter 

If  Syllabus  Array(S_TotalNumberDays,  StudentArray(ST_SyllabusRef, 
SCount))  <>  0  then  'If  not  Dummy  Syllabus 

Call  AddStudentRequired(Scount,  CurrentDate)  '-Sub  to  add  reqs 

to  a  student 

Call  ApplyResources(Scount,  CurrentDate)  'Takes  resources 

from  Resource  A  vail.,  and  applies  to  student  req. 

End  If 

Call  Stay_Roll_orNextphase(S count,  CurrentDate) 

Next 

Next 

'Call  Display  Array  InTable  (StudentArray) 

End  Sub 
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Function  RandomNumber(intHighestNumber) 

Randomize 

RandomNumber  =  Int(Rnd  *  intHighestNumber)  +  1 
End  Function 

Sub  RandomList() 

Dim  ArrayLength 
Dim  Counter 
Dim  SwapWith 
Dim  Temp 
Call  PopulateList() 

'Response.write(M<br>###  Populated  RandomListArray") 

'Display  ArraylnTableOneColumn(RandomListArray) 

ArrayLength  =  Ubound(RandomListArray) 

For  Counter  =  0  to  ArrayLength 

SwapWith  =  RandomNumber(  ArrayLength) 

Temp  =  RandomListArray(SwapWith) 

RandomListArray(SwapWith)  =  RandomListArray(Counter) 

RandomListArray(Counter)  =  Temp 

Next 

'Response.write("<br>###  RandomedListArray") 

'Display  ArraylnTableOneColumn(RandomListArray) 

End  Sub 

Sub  PopulateList() 

Dim  Temp 

Redim  RandomListArray(Ubound(StudentArray,  2)) 

For  Temp  =  0  to  Ubound(RandomListArray) 

RandomListArray(Temp)  =  Temp 

Next 

End  Sub 

Sub  Stay_Roll_orNextphase(StudentID,  Date) 

'If  Student  has  reached  the  last  date  of  the  Syllabus,  and  has  no  more  required  resources,  then  they 
move  to  next  phase. 

'-  If  still  requires  more  resources,  then  they  roll  back  a  class  (CurrenClass  attribute  increases  by  2) 

Dim  RCount 
Dim  TotalResources 

If  StudentArray(ST_PhaseEnd,  StudentID)  =  Date  then  'Check  to  see  if 

they  have  completed  all  events  (resources) 

TotalResources  =  0 

For  RCount  =  0  to  DNumberOfResourceTypes- 1 
'Counts  the  resources  up 

TotalResources  =  TotalResources  + 

StudentArray(ST_F irstResourcelndex+Rcount,  StudentID) 

Next 

If  TotalResources  =  0  then 

Call  GotoNextPhase(StudentID,  Date) 

’Response.write("<br>GotoNextPhase(StudentID):  "  &  StudentID) 
Elseif  TotalResources  >  0  then 

Call  RollBack(StudentID,  Date) 

'Response. write("<br>RollBack(StudentID):  "  &  StudentID) 

Else 
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'Response.  write("<br>Student:"  &  StudentID  &  "  had  negative 
resources  at  phase  end  =  "  &  TotalResources) 

End  If 

End  If 

End  Sub 

Sub  RollBack(StudentID,  Date) 

Dim  Column  1 
Dim  Column2 
Dim  Value  1 
Dim  Value2 
Dim  Row 

StudentArray(ST_CurrentClassNumber,  StudentID)  =  StudentArray(ST_CurrentClassNumber, 
StudentID)  +  2  'FIX  THIS  LATER! ! ! ! 

Value  1  =  Syllabus Array(S_SyllabusName,  StudentArray(ST_SyllabusRef,  StudentID)) 

'Value2  =  SyllabusArray(StudentArray(ST_CurrentClassNumber,  StudentID)) 

Value2  =  StudentArray(ST_CurrentClassNumber,  StudentID) 

Row  =  ReturnRowValues2(ClassDatesArray,  0,  Valuel,  1,  Value2) 

Response.write("<br>  *********  Row  **********;  "  &  Row  &  "  Valuel:  "  &  Valuel  &  " 
Value2:  "  &  Value2) 

'SyllabusArray(ST_PhaseEnd,  StudentID)  =  ClassDatesArray(3,  Row) 
StudentArray(ST_PhaseEnd,  StudentID)  =  ClassDatesArray(3,  Row) 

End  Sub 

Sub  GoToNextPhase(StudentID,  Date) 

'A  new  student  will  be  created  in  the  Syllabus  he/she  is  going  to,  depending  on  student  type  and 
Primary/ Alternate 

'  next  setting  in  the  ClassAsIsArray. 

'Find  which  next  phase.  Only  applies  to  Navy. 

Dim  NextSyllabusName 
Dim  Primary  'True  or  False 
Dim  ClassNumber 
Dim  StudentType 
Primary  =  True 

If  StudentArray(ST_Type,  StudentID)  =  0  then  '0  is  defined  as  Navy  -  See  Array  References,  inc 
If  ClassAsIsArray(C_NumberNavyToAlternatePhase,  StudentArray(ST_SyllabusRef, 
StudentID))  >0  then  '(How  Many,  Studs  Syllabus) 

ClassAsIsArray(C_NumberNavyToAlternatePhase, 
StudentArray(ST_SyllabusRef,  StudentID))  =  ClassAsIsArray(C_NumberNavyToAltematePhase, 
StudentArray(ST_SyllabusRef,  StudentID))  -  1 
Primary  -  False 

End  If 

End  If 

If  Primary  -  True  then 

NextSyllabusName  =  Syllabus Array(S_NextPhase,  StudentArray(ST_SyllabusRef, 

StudentID)) 

Else 

NextSyllabusName  =  SyllabusArray(S_NextAltematePhase, 
StudentArray(ST_SyllabusRef,  StudentID)) 

End  If 

'CreateStudent(NextSyllabusName,  ClassNumber,  StudentType) 

ClassNumber  =  StudentArray(ST_CurrentClassNumber,  StudentID) 

StudentType  =  StudentArray(ST_Type,  StudentID) 
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Call  CreateStudent(NextSyllabusName,  ClassNumber,  StudentType)  ’Sub  in 
ConvertFromDatabase.inc 

Redim  preserve  RandomListArray(Ubound(StudentArray,  2))  ’Random  Array  also  needs  to  be 
redimmed  for  additional  students 

RandomListArray(Ubound(StudentArray,  2))  =  Ubound(StudentArray,  2) 
’Response.write(’’<br>Next:  ”  &  NextSyllabusName  &  ”  Class#:  ”  & 
StudentArray(ST_CurrentClassNumber,  StudentID)  &  ’’  Type:  ”  &  StudentArray(ST_Type,  StudentID)) 
End  Sub 


Sub  TrackResourcesNeeded_Sub(Date,  Syllabus,  ClassNumber,  Resource) 

Dim  TrackResourcesNeeded(3) 

TrackResourcesNeeded(O)  =  Date 
TrackResourcesNeeded(l)  =  cstr(’””  &  Syllabus  &  ’””) 

TrackResourcesNeeded(2)  =  cstr(’””  &  ClassNumber  &  ’””  ) 

TrackResourcesNeeded(3)  =  cstr(’””  &  (DResourceName(Resource))  &  ’””) 

Call  StoreTable(TrackResourcesNeededTable,  TrackResourcesNeeded) 

End  Sub 

Sub  TrackResourcesUsed_Sub(Date,  Syllabus,  ClassNumber,  Resource) 

Dim  TrackResourcesUsed(3) 

TrackResourcesUsed(O)  =  Date 
TrackResourcesUsed(l)  =  cstr(’””  &  Syllabus  &  ’””) 

TrackResourcesUsed(2)  =  cstr(’””  &  ClassNumber  &  ) 

TrackResourcesUsed(3)  =  cstr(’””  &  (DResourceName(Resource))  &  '””) 

Call  StoreTable(TrackResourcesUsedTable,  TrackResourcesUsed) 

End  Sub 

Sub  ApplyResources(StudentID,  Date) 

’  This  subroutine  will  apply  available  resources  for  each  student 
’-  A  student  may  use  1  sim,  1  class,  or  2  flights  per  day. 

’  -Used  resources  are  subtracted  from  the  Resource  Availability  Array 

’-  If  no  resources  are  available,  none  are  used  and  required  resources  build  up  for  that  student. 

’-  A  student  rolls  back  a  class  when  their  ClassEndDate  passes  and  they  still  have  required 
resources 

’  FUTURE:  also,  a  student  does  not  start  classroom  if  other  resources  are  still  required  -  so  they 
are  rolled 

’  FUTURE:  also,  a  student  will  roll  one  10  classes  or  more  behind. 

Dim  Rcount 
Dim  Row 
Dim  SyllabusRef 
Dim  Syllabus 
Dim  ClassNumber 

’Return  row  in  the  array  where  the  RDate  value  in  the  array  =  Date 

Row  =  RetumRowValuesl  (Resources A vailabilityDaily Array,  R  Date,  Date) 

’Call  Display  Array  InTableRows(Resources  A  vailabilityDaily  Array,  Row,  Row) 

If  Row  <>  99999  then 

For  RCount  =  0  to  D_NumberOfResourceTypes-l 

If  StudentArray(ST_FirstResourceIndex+Rcount,  StudentID)  >  0  then 
Response. write(”<br>Date”  &  Date  &  ’’Avail:’’  & 

Resources  AvailabilityDaily  Array  (RResourceRefT oResource Availability Array(RCount) ,  Row)) 
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If 

Resources  AvailabilityDailyArray(R_ResourceRefToResource  Availability  Array  (RCount),  Row)  >  0  then 

Response.  write(":  Is  over  0") 

If  RCount  =  2  and  StudentID=359  then 

Response.write("<br>Date:  "  &  Date  &  ",  ID#"  & 
StudentID  &  "  Needs  "  &  StudentArray(ST_FirstResourceIndex+Rcount,  StudentID)) 

Response. write("<br> Available:  "  & 

Resources  AvailabilityDaily  Array  (RResourceRefT oResource Availability Array(RCount) ,  Row)) 

End  If 

StudentArray(ST_FirstResourceIndex+Rcount,  StudentID)  = 
StudentArray(ST_FirstResourceIndex+Rcount,  StudentID)- 1 

Resources  AvailabilityDaily  Array  (RResourceRefT  oResource  Availability  Array  (RCount) ,  Row)  = 
Resources  AvailabilityDailyArray(R_ResourceRefToResource  Availability  Array  (RCount),  Row)  -  1 

Track  resources  usage 
Syllabus  =  SyllabusArray(S_SyllabusName, 
StudentArray(ST_SyllabusRef,  StudentID))  'Convert  Syllabus  ref#  to  a  Name 

ClassNumber  =  StudentArray(ST_CurrentClassNumber, 

StudentID) 

Call  TrackResourcesUsed_Sub(Date,  Syllabus,  ClassNumber, 

RCount) 

Else 

Response.write("<br>***  Date"  &  Date  &  "Missed  one:  "  & 

DResourceName(RCount)) 

End  If 

End  If 

Next 

'Response.write("<br>From  StudentArray  +  DayplanResources") 

'Call  Display ArrayInTableRows(StudentArray,  StudentID,  StudentID) 

End  If 

End  Sub 

Sub  AddStudentRequired(StudentID,  Date) 

'  This  subroutine  will  find  how  many  resources  that  student  needs  for  that  day,  and  add  to  the 
studentsrequired 

Dim  Column  1 
Dim  Column2 
Dim  Column3 
Dim  Value  1 
Dim  Value2 
Dim  Value3 

Dim  NeededResources() 

Dim  Rcount 
Dim  Row 
Dim  SyllabusRef 
Dim  ResourceValue 

Redim  NeededResources(D_NumberOfResourceTypes- 1 ) 

Column  1  -  DDate 
Column2  =  DSyllabusName 
Column3  =  D_ClassNumber 
Value  1  =  Date 

SyllabusRef  =  StudentArray(ST_SyllabusRef,  StudentID) 

Value2  =  Syllabus  Array  (SSyllabusName,  SyllabusRef)  'Convert  Syllabus  ref#  to  a  Name 
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Value3  =  StudentArray(ST_CurrentClassNumber,  StudentID) 

Row  =  ReturnRowValues3(DayplanResources Array,  Columnl,  Valuel,  Column2,  Value2, 
Column3,  Value3)  ’INEFFICIENT  !!! 

If  Row  <>  99999  then 

For  RCount  =  0  to  D_NumberOfResourceTypes-l 

Resource V alue=DayplanResources  Array(D_F irstResourcelndex+Rcount,  Row) 
If  Resource  Value  >  0  then 

StudentArray(ST_F irstResourcelndex+Rcount,  StudentID)  = 
StudentArray(ST_F irstResourcelndex+Rcount,  StudentID)  +  ResourceValue 

If  RCount  =  2  and  StudentID=359  then 

Response.write(”<br> Adding  Needed,  currently:  "  & 
StudentArray(ST_F irstResourcelndex+Rcount,  StudentID)) 

End  If 

Call  TrackResourcesNeeded_Sub(Date,  Value2,  Value3,  Rcount) 

End  If 

Next 

’Response.write(”<br>From  StudentArray  +  DayplanResources”) 

’Call  Display ArrayInTableRows(StudentArray,  StudentID,  StudentID) 

End  If 

End  Sub 

’Function  ReturnRow( Array,  Column,  Value) 

’Returns  the  row  given  (1)  An  Array  (2)  Column  Number  (3)  Value  seeking 
’Returns  99999  if  none  found 

’Best  used  for  columns  of  data  where  there  are  no  duplicate  values. 

Sub  SQuote(ByVal  InString) 

SQuote  =  ””  &  ’””  &  Cstr(Instring)  &  ’””  &  ”” 

End  Sub 

%> 
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I. 


SAVE  T  OD  AT  ABASE  .IN  C 


Description:  Saves  processes  arrays  back  to  the  database 

<% 

Private  Sub  ClearRecords(NameOfTable) 

Dim  Table 

Set  Table  =  Server. CreateObject("ADODB. Recordset”) 

Table. Open  ’’DELETE  *  FROM  ”  &  NameOfTable,  MM_Conn_is4220Primary_STRING 

End  Sub 

’OLD**  Private  Sub  ClearRecords(NameOfTable, NameOfDateField, ConnectionStr) 

’OLD**  Table. Open  ’’DELETE  *  FROM  ”  &  NameOfTable  &  ”  WHERE  ”  &  NameOfTable  &  & 

NameOfDateField  &  ”>=”  &  StartDate  &  ”  And  ”  &  NameOfTable  &  &  NameOfDateField  &  ”<=”  & 

EndDate  &  ConnectionStr 


Private  Sub  SaveArrayAsTable(NameOfArray, NameOfTable) 

Dim  Table 

Dim  InRowCounter,  InColumnCounter 

Dim  CommString 

Call  ClearRecords(NameOfTable) 

Set  Table  =  Server. CreateObject(”ADODB. Recordset”) 

For  InRowCounter  =  0  To  Ubound(NameOfArray,2) 

CommString  =  ’’INSERT  INTO  ’’  &  NameOfTable  &  ”  VALUES(” 

For  InColumnCounter  =  0  to  Ubound(NameOf Array,  1)-1 

CommString  =  CommString  &  NameOfArray(lnColumnCounter, 

lnRowCounter)& 

Next 

CommString  =  CommString  &  NameOf Array (Ubound(NameOf Array,  1), 
lnRowCounter)&’’)” 

’response.write  ("<br>*!*!*”  &  CommString) 

Table. Open  CommString,  MM_Conn_is4220Primary_STRING 

Next 

End  Sub 

Private  Sub  Save ArrayColumnIntoTable(NameOf Array, NameOfTable) 

Dim  Table 

Dim  InRowCounter,  InColumnCounter 
Dim  CommString 

Set  Table  =  Server. CreateObject("ADODB. Recordset”) 

CommString  =  ’’INSERT  INTO  ”  &  NameOfTable  &  "  VALUES(” 

For  InRowCounter  =  0  To  Ubound(NameOfArray)-l 

CommString  =  CommString  &  NameOf  Array  (InRowCounter)  &  ",” 

Next 

CommString  =  CommString  &  NameOfArray(Ubound(NameOfArray))&")” 
response.write  ("<br>***”  &  CommString) 

Table. Open  CommString,  MM_Conn_is4220Primary_STRING 

End  Sub 

Private  Sub  SaveDailyArrayAsTable(NameOfArray, NameOfTable) 

Dim  Temp  Array 
Dim  Counter 
Dim  Resource 
Dim  Ref 
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Counter  -  0 

Redim  TempArray  (2,  0) 

For  Ref  =  0  to  Ubound(NameOfArray,2) 

For  Resource  =  0  to  Ubound(R_ResourceRefToResource  Availability  Array) 
Redim  Preserve  TempArray(2,  Counter) 

TempArray(0,  Counter)  =  NameOf  Array  (RDate,  Ref) 
TempArray(l,  Counter)  =  &  DResourceName(Resource)  &  m" 

TempArray(2,  Counter)  = 

NameOfArray(R_ResourceRefToResourceAvailabilityArray(Resource),  Ref) 

Counter  =  Counter  +  1 

Next 

Next 

response  write  Snve^^rrnyj^^sT'ctble 

Call  SaveArrayAsTable(TempArray,NameOfTable) 

End  Sub 


Private  Sub  StoreTable(TableData,  DataArray) 

Dim  Row 
Dim  Column 
Dim  Temp 

Row  =  Ubound(TableData,  2) 

Column  =  Ubound(TableData,  1) 

'response. write  ("<br>") 

For  temp  =  0  to  Column 

TableData(Temp,  Row)  =  DataArray(temp) 

'response.write  ("<br>  !!!Temp,"  &  Temp  &  ",  Row:  "  &  Row  &  "DataArray (temp)-'  & 

DataArray(temp)) 

Next 

Redim  Preserve  TableData(Column,  Row+1) 

End  Sub 

Private  Sub  SaveStudentArrayAsTable(NameOfArray,NameOfTable) 

Dim  Table 

Dim  InRowCounter,  InColumnCounter 

Dim  CommString 

Call  ClearRecords(NameOfTable) 

Set  Table  =  Server. CreateObject("ADODB. Recordset") 

For  InRowCounter  =  0  To  Ubound(NameOfArray,2) 

CommString  =  "INSERT  INTO  "  &  NameOfTable  &  "  VALUES(" 

CommString  =  CommString  &  '""  &  SyllabusArray(0,  NameOfArray(ST_SyllabusRef, 
lnRowCounter))&  '""  & 

CommString  =  CommString  &  NameOfArray(ST_StartClassNumber,  lnRowCounter)& 

tt 

CommString  =  CommString  &  NameOfArray(ST_CurrentClassNumber, 

lnRowCounter)& 

CommString  =  CommString  &  NameOfArray(ST_PhaseStart,  InRowCounter) & 
CommString  =  CommString  &  NameOfArray(ST_Type,  InRowCounter) & 

CommString  =  CommString  &  NameOfArray(ST_InPhase,  InRowCounter) & 
CommString  =  CommString  &  NameOfArray(ST_TotalResourcesRequired, 

InRowCounter)  & 

CommString  =  CommString  &  '""  &  NameOfArray(ST_PhaseEnd,  InRowCounter)  & 

"  " 

CommString  =  CommString  &  NameOfArray(8,  InRowCounter) & 

CommString  =  CommString  &  NameOf Array(9,  InRowCounter) & 
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CommString  =  CommString  &  NameOfArray(10,  lnRowCounter)& 
CommString  =  CommString  &  NameOfArray(ll,  lnRowCounter)& 
CommString  =  CommString  &  NameOfArray(12,  lnRowCounter)& 
CommString  =  CommString  &  NameOfArray(13,  lnRowCounter)& 
CommString  =  CommString  &  NameOfArray(14,  lnRowCounter)& 
CommString  =  CommString  &  NameOfArray(15,  lnRowCounter)&  ")" 
Table.Open  CommString,  MM_Conn_is4220Primary_STRING 
'response. write  ("<br>"  &  CommString) 

Next 

End  Sub 

%> 
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APPENDIX  F.  REQUIREMENTS  REFINEMENT  SURVEY  I 


OPS  Survey:  Aviation  Training  Forecaster  Project 

LCDR  Randall  Bostick  &  LCDR  William  Booth 


Good  production-related  decisions  require  usable  and  timely  information.  The  project  goal  is  to 
provide  better  information  to  enable  the  best  possible  production  related  decision  making.  Your 
thoughtful  responses  will  help  us  create  the  best  product  possible  for  you.  Thank  you  for  your 
time. 


NAME/RANK: 

EMAIL  /  PHONE#: 

Command: 

Interest  in  Project  (1-Low,  5 -High): 

l 

2 

3 

4 

5 

Strongly  Disagree 

Disagree 

Not  Sure 

Agree 

Strongly  Agree 

Information  for  Decision  Making 

The  information 
would  be  useful 

(Circle  One) 

We  already  have  access 
to  this  information. 

(Circle  One) 

1)  The  number  of  events  (flight,  simulator,  classroom)  needed  per  week 
for  the  next  1-4  weeks  to  get/keep  students  on  track.(IAW  TTT.) 

1  2  3  4  5 

No  /  Not  Sure  /  Yes 

2)  The  number  of  events  (flight,  simulator,  classroom)  needed  per  week 
for  the  next  1-12  months  to  get/keep  students  on  track  (IAW  TTT.) 

1  2  3  4  5 

No  /  Not  Sure  /  Yes 

3)  The  negative  or  positive  effect  on  production  due  to  planning  to  fly 
less  or  more. 

Example:  Flying  over  the  weekend  will  help  to  catch  up 
by  how  much  (what  number  of  events.) 

Example:  How  will  taking  a  Friday  off  effect  production. 

Example:  After  X  weeks  of  high  cancellations  due  to  weather, 

Y  number  of  events  need  to  be  produced  to  catch  up. 

1  2  3  4  5 

No  /  Not  Sure  /  Yes 

4)  The  maximum  number  of  students  a  phase  can  handle  (at  one  time 
while  continuing  to  produce  students  within  required  TTT) 

1  2  3  4  5 

No  /Not  Sure/  Yes 

5)  Number  of  students  to  send  to  each  next  phase. 

Example:  Phase  completing  X  amount  of  students  in  a  class 
may  be  unnecessary  since  the  next  phase  cannot 
handle  all  of  the  students  in  that  class. 

1  2  3  4  5 

No  /  Not  Sure  /  Yes 

6)  Identifying  possible  resource  sharing  opportunities. 

Example:  Phase  A  uses  the  same  airplanes  as  phase  B.  In  a  few 
weeks,  phase  B  is  projected  not  to  need  all  of  their 
planes  for  events.  Phase  A  is  projected  to  need  more 

1  2  3  4  5 

No  /Not  Sure/  Yes 
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aircraft  at  that  time. 

7)  Syllabus  Design:  Production  effects  of  lengthening  or  shortening  the 
syllabus  TTT. 

1  2  3  4  5 

No /Not  Sure/ Yes 

8)  Syllabus  Design:  Identification  of  varying  event  demand  driven 
purely  by  event  placement  within  the  syllabus. 

1  2  3  4  5 

No /Not  Sure/ Yes 

Additional  Comments: 
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APPENDIX  G.  REQUIREMENTS  REFINEMENT  SURVEY  II 


Aviation  Training  Forecaster  Project 

LCDR  Randall  Bostick  &  LCDR  William  Booth 


The  primary  project  goal  is  to  develop  a  tool  to  generate  useful  information  for  assessing  the 
impact  of  alternative  production  strategies  through  forecasting  and  “what-if  ’  analysis.  Your 
thoughtful  responses  will  help  us  create  the  best  product  possible  for  CNATRA.  Thank  you  for 
your  time. 


NAME/RANK: 

EMAIL  /  PHONE#: 

Command: 

Interest  in  Project  (1-Low,  5 -High): 

l 

2 

3 

4 

5 

Strongly  Disagree 

Disagree 

Not  Sure 

Agree 

Strongly  Agree 

Information  for  Decision  Making 

The  information 
would  be  useful 

(Circle  One) 

We  already  have  access 
to  this  information. 

(Circle  One) 

1)  The  impact  of  alternative  production  strategies  to  meet  changing  fleet 
requirements. 

Example:  Suddenly,  fewer  aviators  are  needed  in  a  pipeline.  What  impact 
would  the  following  have,  for  example: 

a.  Raising  the  NS S  to  increase  attrition  in  certain  stages. 

b.  Allowing  students  to  complete  training  even  if  there  is  no  slot  for  them. 

c.  Diverting  some  students  to  another  pipeline,  etc.. 

1  2  3  4  5 

No  /Not  Sure/ Yes 

Is  so,  what  is  the  source? 

2)  The  impact  of  reducing  TTT  while  maintaining  the  same  training 
requirements. 

Example:  To  enable  better  reaction  to  fluctuating  fleet  demands,  it  may  be 
advantageous  to  reduce  TTT  as  much  as  practicable  without  reducing  the 
quality  of  training.  How  would  production  be  effected  if  a  given  number 
of  non-event  days  (fluff)  were  removed  from  each  phase? 

Example:  How  much  would  increasing  or  decreasing  TTT  effect  the  on- 
time  completion  rate? 

1  2  3  4  5 

No  /Not  Sure/ Yes 

Is  so,  what  is  the  source? 

3)  If  pipeline  changes  are  being  considered,  how  might  production  be 
effected? 

Example:  New  training  requirements  due  to  changing  fleet  aircraft 
requires  new  training  phases  or  existing  phases  to  be  modified.  How  will 
production  be  effected? 

1  2  3  4  5 

No  /Not  Sure/ Yes 

Is  so,  what  is  the  source? 

4)  The  number  of  resources  (aircraft,  instructors,  simulators,  etc)  required 
in  each  phase  of  training  to  meet  TTT. 

1  2  3  4  5 

No  /Not  Sure/ Yes 

Is  so,  what  is  the  source? 
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5)  The  fiscal  impact  of  alternative  production  strategies. 

1  2  3  4  5 

No /Not  Sure/ Yes 

Example:  To  enable  the  most  cost  efficient  structuring  of  training  related 
support  contracts,  would  it  be  advantageous  to  project  training  demand 

Is  so,  what  is  the  source? 

fluctuations? 

Example:  Given  current  contract  stipulations,  how  much  will  overtime  (or 
surge)  situations  costs?  Could  overtime  situations  be  reduced?  If  so,  by 
how  much? 

Additional  Comments: 
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